Re: Decide on official Isar release cycle

[Baurzhan Ismagulov <ibr@radix50.net>]

On 2025-12-16 09:06, 'Jan Kiszka' via isar-users wrote:
> On 16.12.25 08:58, Anton Mikanovich wrote:
> > I think Isar is looking stable enough to have v1.0 release.
> > But we should choose the date carefully, because it will require some
> > pre-release work (like retesting all the targets) every year on this
> > period.
> > Some steps I hope will be automated soon, while some still require manual
> > involving.
> > 
> > Also following should be taken in account:
> > - Incomming commits activity. It is usually variable during the year.
> > - Debian releases. Few months after and before Debian release date don't
> > look
> > like stable base point.
> > - Any holidays when people can be on vocations.
> > 
> > Having all this in mind my suggestion is February.
> > 
> > Regarding the period of releases not sure we need to have 4 minor
> > releases per
> > year, because preparations will probably be the same as for major ones.
> > Maybe
> > having one stable release every year will be more useful and will allow
> > to have
> > some big changes more "polished" to the moment of the release.
> 
> I think someone at the meetup summarized this nicely: "One release per
> year is like no release." If you want people to synchronize on the
> releases, you need at least 2 per year, rather 3 or even 4.

In general, I'm ok with quarterly releases if this serves anyone.
We've already been working since some time on automating the necessary parts.

What I'd like to understand is who needs this and for which reasons. When we
update the process later, we'd re-check against these inputs.

Regarding 1.0, it was about selling the product to potential users which I can
understand.

Regarding quarterly releases, I only remember Cedric talking about it but
haven't clearly heard why -- @Cedric, was it that you released your product
quarterly? And quarterly Isar updates would help you in which way?

In my experience, many downstreams upgrade seldom (usually once per product
release, which is roughly two years). I perceived reluctance to upgrade Isar
because the custom distro aligns with cip-core and cip-core hasn't upgraded [at
the time of discussion]. That said, yearly custom distro upgrades are also
skipped till the product release.

We could think about starting with two releases per year, gaining experience
(esp. regarding larger code changes) and seeing which effort it requires.

We could discuss two-year major releases but maybe rather as an upper limit --
if an incompatible feature is merged, it would make sense to make a major
release earlier.

Yes, we don't have a stable branch and currently I'd like to avoid it if at all
possible. Regarding version naming, I'd keep the major-minor scheme for now.
Debian releases when it's ready, and we'd like to take the time plan as
guidance and not literally.

With kind regards,
Baurzhan

-- 
You received this message because you are subscribed to the Google Groups "isar-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/isar-users/aUE6MR5P0zY5J_PR%40abai.de.