Re: Decide on official Isar release cycle

["'Jan Kiszka' via isar-users" <isar-users@googlegroups.com>]

On 16.12.25 11:53, Baurzhan Ismagulov wrote:
> 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.

isar-cip-core is updating isar on EACH of its own quarterly release. I'm
currently preparing the next one, qualifying the isar "next" branch for
it, having found and fixed various isar issues along that. Without a
higher frequency of releases on Isar side, I will not change this pattern.

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

That's the absolute minimum, but will likely not change a lot
downstream, at least as long as we find too many issues via the
downstream layers, thus potentially to late for a release.

> 
> 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.
> 

I would also not vote for stable branches at this point yet. But the
less frequently you release major versions, the higher the need for
those may become.

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

-- 
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/224d4e98-d5aa-43fa-951c-d2fa0b478c15%40siemens.com.