Next major version, diaspora* 0.8.0.0


(Flaburgan) #21

We have two big pull requests ready for review, the migration and the API (almost ready, looking at your rhythm of dev it’ll be in a few days). In my opinion, they are enough to justify a major release.
So I propose the following:

  • We set these two features as blockers for the next major release (I just added the 0.8.0.0 milestone to the API PR)
  • Everything which is ready before these big PRs are merged and which can not be included in a minor release will also be shipped in the coming major. As the reviews will take time, it should allow some other features to be integrated. That can include some of the feature @HankG listed above, but they should not be a blocker in my opinion.

What do you think?


(Hank G) #22

I’m totally on board with this. Do we want to add 2FA as a blocker as well since that’s a big change with a staged PR?


(Flaburgan) #23

It is flagged with the 0.8 milestone so I would say yes. But hopefully it’s merged before the migration and the API, the review should be much quicker, it already went through several passes of review.


(goob) #24

Seed migration (including a front-end) and a working API are two big steps towards a version 1.0.0.0! See this discussion: Requirements for a 1.x.y.z release.

@HankG, the policy so far, since diaspora* has been a community-run project, is to release a major version once there is a sufficient number of changes (or even one huge change). Your list is, I think, too conservative; two or three of the more major changes in your list would merit a major release on their own.

All of the things you list will be valuable additions, but I think you’ve got 3 major versions in your list. It would be a bad thing, I think, to hold up the release of seed migration, your API or post editing because of one other feature that no one has started. Any of those three features should be released as soon as they are ready,* because they’re all ones that the community has been crying out for.

*Of course, if there is another feature that is almost ready, we could wait for a short while so that can also be included in the release; but a release shouldn’t be held up unreasonably.

I would say a ‘blocker’ should be restricted to something that (a) absolutely has to be included as soon as possible; (b) needs to be included in order for something else being released to work properly; or (c) fixes a regression and would normally be included in a minor release. If the pace of development picks up from that in the past few years, major releases would become more frequent as more features and other major changes are made more quickly, so anything missing out on one major release would not necessarily have to wait many more months to be released.


(Hank G) #25

I’d like to pick this apart a bit. Unless there is a dramatic change in the number of developers in the next seven months I’m probably the one that’s going to be doing most of the work on that list. I’m not even sure if that list is achievable for me personally in that time frame due to other commitments. So no, I don’t think that’s a conservative estimate. There will be other cats and dogs things that have to happen in there too.

If we need to do major releases to get certain features out and we have an arbitrarily high bar for when a major release gets pushed that means we could have years between releases where good changes are just sitting there stagnating. The copy/paste images PR is waiting for a 0.8.0.0 release because of a library change. Is that supposed to sit there until 2020 or whenever we get even more stuff done? That seems like a very bad decision from multiple perspectives. From the developer perspective it is bad because the code essentially never gets used. It kills momentum because there is no “win”. It also has a huge integration burden as these things aggregate over years and versions and that same person has to go fix things that may have broken as things migrated. It also is bad from a user perspective because the entire project looks like nothing is happening with it when in reality there are good things actually going on.

I can’t imagine waiting for another year to go by to bump major versions. The release guidelines state even something as small as the image copy/paste has to wait for a major release because of a library change. So something as big as the migration, or the API, are going to need to come with a major version bump.


(goob) #26

@HankG, I think you’ve read my message the wrong way around.

What I said is essentially what you’ve said in your last response: that we shouldn’t wait for a big list of features to be completed before making a major release; rather, a major version should be released as soon as there are a few changes that merit a major release (even a single change in the case of something as major as seed migration or the API).

In your earlier comment (the one with the proposed list of features for inclusion), you said"

I think it would be a bad thing to aim to wait until August 2019 before releasing our next major release, unless nothing meriting a major release is completed before then. If the API or seed migration is completed earlier – which they hopefully both will be – we should release version 0.8.0.0 at that point. If other features are completed, then August 2019 might be the release date for 0.9.0.0 or even 0.10.0.0.

We absolutely shouldn’t:

or

I think we’re agreeing with each other.


(Hank G) #27

Ah sorry about that. You are right. My list was more a target to shoot for not the blockers for a release. I figure try for something somewhat ambitious but realistically achievable and then bundle it up with whatever we actually have. I wanted to have some list that we could talk to like I did for the API work. It’s something we can use to get people excited about the development, report on it, et cetera. The blocker blockers I’d see for August would be API and maybe the pod migration (I think that’s what is meant by seeding), although I didn’t explicitly state that.

I don’t know what a major release entails which is why I wasn’t putting out having multiple ones in one year as well. If I understood how much work went into a major release versus a minor release then I could make a better decision than just following the status quo of how the team did this for 0.6 and 0.7. Perhaps multiple major releases per year would be a fine idea, I just don’t know.

Honestly there were no responses anywhere to this topic for awhile so I was getting nervous that no one but me would be willing to do a major release in 2019. That would have meant all this work was going to do nothing but sit on a shelf for god knows how long. I’m glad we are having this exchange to dispel that notion.


(goob) #28

You can see when major versions have been released at https://wiki.diasporafoundation.org/Roadmap – the first few were released 3–6 months apart, with the last few bring a year apart, only because development slowed down somewhat as previously active contributors had to slow down their contributions for all sorts of reasons. And while Senya has been hard at work on the seed migration, it has necessarily taken a lot longer than imagined because of the next for extensive review and testing.

The only reason for an August release was to celebrate the anniversary of diaspora* becoming a community-run project and to use that to promote the project a bit. If anything, it was a case of hurrying up a release to have something ready to release in August, rather than delaying a release until August.

Minor releases tend to include bug fixes and minor improvements. A new feature or anything requiring a database migration would merit a major release. ‘Major’ has the sense more of ‘significant to the end user’ than ‘a major amount of work for the people releasing the software’. Things for a major release can require more code review and testing than the fixes in a minor release, so there is more work required prior to releasing, to make sure everything really is ready to be released, and this can delay a release.

As I’m not a dev I have only limited understanding of the technical aspects. What I’ve said is correct as far as my limited understanding goes, but I should probably leave it there and let those who actually know what they’re talking about take over, in case I’ve said anything that is in fact incorrect. Hopefully not!