Stable release 2.5

Hello everyone,

As discussed during our last meeting, I’m opening this topic for us, the “council” to formally decide to release our current beta version as a new stable version.

The formulation of the decision is: do we release the current beta version as a new stable version after at least one week of the latest beta release and if no important enough new bug to stop that process are encountered?

It is important that other groups than the core dev-team express themselves in case they think that something needs to be done before this release. I’m especially thinking about the translation, documentation, distribution and doc group.

Ping @juju, @ljf, @Maniack_Crudelis, @Moul, @opi, @theodore, @Jibec, @CaptainSqrt2_, @scith, @tostaki, @heyyounow

On the boring semantic part, I’m think that we should go back to odd/even for testing/stable version number because we haven’t updated our toolchain to be able to do 2.5.0-beta3 version numbers.

Thanks Bram, so we are the small group in a garage…
You know, somes small groups in a garage will dominate the world.

Scith, don’t worry, we’ll have our big tower with our very big logo “Apps Group”.

Well, in our small garage, at the end of the yard. All it’s ok, the CI works well on 2.5.

Using 2.5.3.1 on production for some days now, and everything works fine.

however, for UX reasons I’d like https://github.com/YunoHost/yunohost/pull/216 to be merged.

About version number, I rather go with actuel semver, and release 2.5.4 as next stable, but I’ll agree with 2.6.0 as well, if everyone else prefer odd/even numbering

About the version number, I don’t have a strong opinion on this, but I’d say there’s no choice better than the other.

Right now we are in the process of releasing so it looks easier to have odd/even versions to easily know if a release is testing or stable. But once we’ll want to merge some new PR which are not new important feature, we’re gonna wonder “Shall we push this as a new 2.5.x or in 2.7.x” ? Keeping pushing in 2.5.x feels weird if there’s a 2.6 released… And pushing in 2.7.x breaks the semantic if there’s no new important feature. Also if the goal is to release often, we’ll soon end up with 2.42 …

To me, remembering which 2.5.x is stable or testing is not a huge deal. We can have a small lookup table somewhere (or even display it in the footer of the webadmin and in CLI ?).

Anyway, every versioning method sucks in some way. I’m not voting for A or B, let’s just pick one and stick with it.

We need to update the documentation before and prepare some announcement.

Coucou, je trouve que ce que vous faites est génial
BISOUS

3 Likes

Do we plan particular communication for the release, e.g. a post on LinuxFR ? Last one was for the 2.0 in june 2014. I could write a draft if people think it’s a good idea.

+1 for press release, both french (linuxFr, journalduhacker, …) and english (hackernews, …)

I can help with writing/reading

There is already a LinuxFr post I started:

It’s not ended and needs external contributions.

The formulation of the decision is: do we release the current beta version as a new stable version after at least one week of the latest beta release and if no important enough new bug to stop that process are encountered?

Translation: ready to release. We did set up Weblate, we communicated, we do not have yet enough translators to expect any other big updates.
The last decision I wish to have before release is to give me your aproval to allow anyone to add a new language without asking anyone (it’s what is done in https://hosted.weblate.org, I assume it’s safe). The Redmine ticket: https://dev.yunohost.org/issues/668

We should be able to release Soon™ :slight_smile: . Trying to summarize the remaining todo :

  • update build.yunohost.org with links to latest ISO image and Raspberry image
  • fetch latest translations (issue with weblate to be solved)
  • translate the certmanager doc to french
  • validate/merge some ongoing PR about doc, install script, fix for LE (list here https://dev.yunohost.org/versions/7)
  • finish/validate the press release

I think that we should put everything in the redmine roadmap so we have the todo in one and only one place :wink: