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
Hm - the leading zero is not fair any more to Diaspora, I agree. But the users might be confused to see an “1” than a “8”.
So I propose the version number as “8.0.0” (just drop the leading zero)
I think I disagree. 
Even with the current scheme, a 1.0.0.0 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.
1 Like
I can absolutely life with the 1.x Version.
I’d still kind of like to wait until the things raised in Requirements for a 1.x.y.z release have been included. The main lists I find in that thread are:
But reviewing those, perhaps we’re not far off. I’d be interested to hear what people who contributed to that thread think now.
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.
1.0.0 is OK, and I also think that this list is almost fulfilled. Missing is the point about being able to do a minor upgrade from the admin interface but honestly I don’t think it is as important as before. Moderation work is mostly done with Enhance Reports by tclaus · Pull Request #8239 · diaspora/diaspora · GitHub even if I would have loved to see Podmin should be able to forward a report to the source pod podmin · Issue #7316 · diaspora/diaspora · GitHub also included. API and migration will be done. Chat is something we don’t want anymore. A refresh of the UI would probably have been nice but we won’t rewrite the front-end before this date for sure, and it isn’t worth investing much in the current front-end. If you have some ideas about “low hanging fruits” changes to make it a bit more modern I can probably do some CSS work.
These are chaotic times and I’m a chaotic person, so I don’t want to make any commitments here
Let’s just not exclude the possibility of that chaos may take the form of me contributing something useful.
1 Like
As the threads are split now, I post this back to this thread:
In other news, as I released 0.7.18.0 yesterday, I didn’t prepare a 0.7.19.0 (so no new milestone or changelog section), as I think we are all focusing on the next major release now, so unless there is a security hotfix needed or any other change should be backported to 0.7.x, this probably was the last 0.7.x release.
Hello, so, back on this topic as I’m available the full day today. Can we try to gather a list of what we still need to do for the release?
Where we still need to do some work:
- The biggest piece is the migration UI (#8274, @tclaus what is the current status exactly?) also coming with the new registration page (#8285, ready for review) explaining how to migrate
- Do we want to continue to upgrade our stack to support Ruby 3.1 (#8369, work to be done) and with it OpenSSL3 and so Ubuntu 22.04 @supertux88 ?
- What work is still needed on the official website @denschub ? Can I help?
- Ensure that the installation and update guides are up-to-date
- Then there is the communication work, prepare the blog post, probably create a new artwork for it?
- What do we want to do with Insporation? Should it also be released at that time? On @jhass repo or included as official?
- Is there something else which has to be done to be able to release?
I also went through the list of open PRs and here are the one which are currently working well and can be merged easily I think:
- Re-introduce likes on comments (#8203, already reviewed by @comradesenya, actually deployed in prod on diaspora-fr.org, UI can surely be improved but is good enough to be used in the current state. Ready for review / merge by a core team member)
- Multi-select aspects on mobile (#8217, ready for review)
- Add a more detailed modal when reporting a post or a comment (#8035, ready for review) which once merged, will allow Enhance Reports #8239 to be rebased on it.
- API: update Search endpoint to be aware of ignored users (#8363, ready for review) should also be merged as this is a bug.
- Less important but still nice for podmins: Let podmin send private messages to local users (#8246, ready for review)
Do you agree with this list? How can I help?
I realise that I never replied to this point, as I went away and have been pretty busy since then.
There are still some things I’d like implemented for an app to be considered ‘1.x’, particularly ease of installation and maintenance of a pod, but the changes that are coming with the next version are pretty fundamental; and, if everyone else thinks that the next release should be 1.x rather than 0.8.x, I don’t have any objections to that.
On Dennis’s point about dropping the four-part schema (a.b.c.d) in favour of three digits, I think I’d like to keep four, as major releases (which have, until now, been the ‘b’ in that schema) are not usually the kind of changes that would merit, in my view, changing the first digit in the version number. I wouldn’t want to follow Mozilla’s lead (sorry, Dennis) by changing the initial digit every few weeks – after taking 9 years to reach version 5, Firefox surpassed version 100 only 11 years later after adopting a three-part schema. I’d prefer a new initial digital to be reserved for a quantum step forward in Diaspora’s code (a combination of new features, improved performance and/or UX).
This next release certainly achieves that, so I’m happy to change that rusty old 0 to a 1.
The migration UI is merged on societas. For me, it is ready to review / merge.
I’d suggest to focus on code-tasks for now. I’ll reach out to you at a later point, when I’m clear on … that thing we’ve talked in private. That might have an impact on how we structure the install docs. Also, my goals have shifted significantly - away from “build the fanciest thing where we have the most flexibility”, to a viewpoint of “how can we fit our needs with as little custom code as possible”.
I’ll try schedule some time to seriously think about the UX here in the next two weeks. (sorry, can’t be more specific than that at the moment.) I’ll be nice and productive - I promise.
No offense taken. I just stopped caring about version numbers. 
But just to clarify, I think you might have misunderstood my proposal. The proposal was very explicitly not to release a new major version every six weeks or whatever.
While I hope that we can get back into a regular release schedule eventually, those will continue to be minor releases - i.e. they’ll be bumping the second digit.
In a bit, what I’m actually proposing is probably to just trim away the first 0.. We’ve been treating the second digit as a “major” release digit, and so far, we’ve only had seven major releases since the project’s incepction in 2012. Or, in other words, 0.6 major releases a year (nothing that we’ve been pretty inflationary with the releases earlier in our history). I don’t think that’s bad.
So, essentially, we’d now be at version 7.0.0, and development would be at 8.0.0. However, jumping to that is confusing, and I like the idea of having an official 1.0.0 release and going form there. After that, the next minor release would be a 1.1.0 - and a security hotfix would be 1.0.1. I can’t even imagine what a version 2 would be like - but that’s certainly not happening in Firefox-release-train schedules.
I’m not going to bikeshed on this, and if you really like the four-digits more, I’ll not block that. However, I suggested this move because a) we kinda violate semantic versioning at the moment with our four-digits (that actually made a little network-observation tool I started building harder), and… quite frankly… we don’t need four levels of distinguishing.
1 Like
OK, thanks for your explanation. I see what you mean, and as you point out, we’d be reaching version 8 with the next release, after 10 years of the system. On that basis, and if what were considered major releases (for instance, introducing a new feature) will henceforth be considered minor releases, I’m happy to move to the three-tier system you propose.
diaspora* Version 1.0.0. How exciting!
1 Like
Yes, we want to upgrade to ruby 3 (as 2.7 will be EOL too next year, so we need to), but in the issue you linked is the current state of that. So there are known issues with 3.0 (but no solutions yet, so if you have ideas how to solve these problems, I’m open for them), and there are unknown issues with 3.1 (I did a really quick tests and tests didn’t even start but I didn’t look further into them, as we need to work in the problems for 3.0 first anyway). OpenSSL 3 needs ruby 3.1, so that’s still unknown to me how much work that is, but we should at least start supporting 3.0.
There is also some more work that can be done regarding rails, for example migrate to the new zeitwerk autoloader (with which we aren’t compatible at the moment) which then will allow us to upgrade to rails 7.
But I’m not sure if any of this should be a blocker for the release, we probably just can fix stuff like that as a minor release?
I basically agree with what @denschub already said about this. We didn’t change the b often so far (major releases, breaking changes, …), when we did releases every few weeks, we increased the c (minor release, to get small features, improvements and fixes out there, while we are still working on the big changes for the next major release). We never did anything with a, which proofs we don’t need a (so we basically can just drop it, but start counting with an official 1.0.0 release again). We still won’t do major releases often, so the first digit will only go up slowly. And having only 3 numbers makes everything simpler and it’s easier to talk about big major releases just with “diaspora <number>” instead of “diaspora 0.<number>”.
Okay, I have to revise that: I can’t actually review Likes on Comments. I spent more than 15 hours trying to build a UI that I like, and I failed. Every single attempt felt way too noisy for me, and I liked absolutely nothing. So I’m simply not the right person to provide feedback for that particular feature.
I’ll have a look at migrations soon, though.
I’ve been meaning to draft a blog post for the anniversary. It was originally going to ask for people to help in the push to get the next release ready for that anniversary, but I’ve left it waaaay to late for that, so I’ll put something together that’s more relevant to today’s situation.
1 Like