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.
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.
@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.
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.
@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.
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.
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!
So… We started to talk about it in an internal thread, but the insporation app, available on iOS and Android, is about to be ready. Also, the 27th of August, it will be 10 years that the project became a community project. I would be awesome to release 0.8 for that date.
I think we are more efficient when we are connected at the same time and work together, maybe we could plan some evenings and try to see what we can merge?
It would be a wonderful achievement, and a very fitting date to release this big step forward for the project, but of course it depends on the availability and commitments of those who will be doing the work.
Y’know what… if y’all want to target that date, I’ll commit to spending some time pushing the website and documentation stuff into a releasable state. It makes a lot of sense to have that ready at the same time, and I assume I’m more productive doing that stuff as opposed to Ruby code.
(Additional side note and potentially unpopular opinion: IMO, diaspora* should drop the a.b.c.d version number, and just declare 0.8.0.0 to be 1.0.0. The project is already known to be the most stable project of the bubble we’re in, so… why not.)
I think I disagree. Even with the current scheme, a 184.108.40.206 is bound to happen eventually, it’s just that nobody made that call yet. I’d be surprised if anyone would be confused seeing a 1.0.0 release that follows a 0.7.x.x - after all, the first digit changed so that’s significant.
I also really like the symbolism of a 1.x release, and I particularly dislike the symbolism of staying at 0.x forever. But maybe that’s just me.
I’m with Dennis here, I think the next release should probably be 1.0. And I think people can see the difference between 1.0 and the previous 0.x.
If we wait for specific features there is probably always something somebody wants to wait for. 1.0 means for me, that a software is stable and is basically out of beta. And for diaspora this is basically the case since a long time. And the second thing is, with the migration in the next release, it basically marks that all original plans are done now. So I don’t really see a reason why we should wait longer for the 1.0 step, because it already feels kinda weird that it’s still 0.x which just looks wrong compared to how stable it runs.
So I didn’t really participate in the discussion back then, but for me probably the only things required would have been the new stable federation (because the old federation was a mess and so broken we could never have say that’s 1.0 … but federation works really stable now since a long time), and maybe the migration, since that was an original promised feature. Everything else is of course cool, but it just feels silly for me to block 1.0 for longer at this moment.
We can still include the other features in future versions.