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