On the “should we do 0.8.0.0” would the REST API feature need to be integrated in a major point release? If so where is the development timeline on that? If it is somewhat near the status of these features and would need to wait for a full point release then I’d say hold off on that. However if that is somewhere where we could have a major point release just for that alone within a few months of 0.8.0.0 then I guess it’s moot.
As far as I know, no progress is done on the API side at the moment, so it should not be a blocker.
And for the question “should we release for the birthday” well, it’s past so obviously the answer is no 
1 Like
Yeah I could tell the discussion about the actual release date had come and gone but the question of whether these were sufficient features to warrant the number bump seemed still relevant.
As there is very few progress on those topics, I don’t know. Maybe someone will step up and the API will be done before the import feature? Who knows…
It’s something I’m hoping to work on actually. I’m not making that my warm up rounds though. I’m looking to do smaller surgical things, preferably that would expose me to both back end and front end, before tackling something larger like that.
This topic was created in July with the idea of an imminent major release in August 2018 which there weren’t enough features for. If we decide to keep with the August release tempo for the major release, which I think would be a good idea, then thinking ahead to the next several months of development for what we could target for August 2019 would be a good thing. Now that the API is getting ready to go into its next stage of development I am looking at what I think could be a good set of major features for 0.8.0.0, based on the above but with some additional ones. These are things that I as user would really like to have, that I’d be willing to work on, and that I think are feasible to do in a 6-7 month time frame. Here are my thoughts for what I’d like to accomplish for 0.8.0.0 and what I’d be willing to sign up to work towards. Thoughts? I can make this a new thread if that’s preferred.
- API in production (almost staged for PR)
- Posts
- Liking Comments
- Disabling Comments
- Closing polls
- Editing posts
- Editing Comments (if protocol already supports that as well)
- Photos
- Streaming instead of greedy load
- Pasting directly into posts (already staged for PR)
- Mobile
- Aspects multiselect
- Autocomplete names when posting/commenting
- Archive Import (already staged for PR)
- Two Factor authentication (already staged for PR)
- Advanced search and custom streams
1 Like
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?
1 Like
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?
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.
1 Like
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.
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.
1 Like
@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.
2 Likes
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!
1 Like
Why isn’t the groups feature first priority?
Without groups, there’s nothing.
3 Likes
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?
@tclaus @supertux88 @jhass (and maybe @comradesenya?)
2 Likes
Like the idea.
But as a young father I could hardly say when I am available or not. In july and august me and my family are on „parents vacation“.
But I am prepaired to join in and submit (smaller) fixes if it is possible.
The 10 anniversary is a great date for a new major.
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. 
1 Like
(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.)
1 Like