Decide on official Isar release cycle

[Clara Kowalsky]

Hi,

last week at the Isar Community Meetup, the desire was expressed to
finally have a v1.0 Isar release to demonstrate project maturity, as
well as to have more releases per year, ideally quarterly.
So far, the approach has been to release approximately one minor release
per year, which brings us to v0.11 at present.
My suggestion would be to follow a similar approach as Debian and have a
major release every two years, along with a minor release every quarter.

How should we proceed? Which strategy do we want to establish?
Ideally, we could release the first major version in January and then
proceed with a quarterly cycle.

Best regards,
Clara Kowalsky

[Jan Kiszka]

On 16.12.25 08:37, Clara Kowalsky wrote:
> Hi,
>
> last week at the Isar Community Meetup, the desire was expressed to
> finally have a v1.0 Isar release to demonstrate project maturity, as
> well as to have more releases per year, ideally quarterly.

Thanks for reminding of this fairly important topic.

> So far, the approach has been to release approximately one minor release
> per year, which brings us to v0.11 at present.
> My suggestion would be to follow a similar approach as Debian and have a
> major release every two years, along with a minor release every quarter.
>
> How should we proceed? Which strategy do we want to establish?
> Ideally, we could release the first major version in January and then
> proceed with a quarterly cycle.

In contrast to Debian, there is no stable branch strategy for Isar in
sight, is there? In that light, I would just go for a time-driven
quarterly release with accordingly named tags, e.g.

2026.01, 2026.04, 2026.07, 2026.10

or "v2026.01" if preferred to start with a letter.

Jan

--
Siemens AG, Foundational Technologies
Linux Expert Center

[Anton Mikanovich]

Hello Clara,

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.

[Jan Kiszka]

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.

[Baurzhan Ismagulov]

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

[Andreas Naumann]

Hello,

Am 16.12.25 um 09:06 schrieb 'Jan Kiszka' via isar-users:

I second that having quarterly tags would be nice. As for QA, I think
having a grace period of maybe 2-4 weeks where only fixes are applied to
master would be enough. That should give interested downstream projects
enough time to check if everything is still working and avoid extra test
effort for the maintainers.

Regarding the naming, first the common v2026.x scheme felt a bit strange
to me, but now I think the absence of major/minor/patch levels is
actually an advantage because it avoids people having API/QA
expectations that usually come with it.

so far my 5cents, regards,
Andreas


>
> Jan
>
Andreas Naumann

--
emlix GmbH
Headquarters: Berliner Str. 12, 37073 Göttingen, Germany
Phone +49 (0)551 30664-0, e-mail in...@emlix.com
District Court of Göttingen, Registry Number HR B 3160
Managing Directors: Heike Jordan, Dr. Uwe Kracke
VAT ID No. DE 205 198 055
Office Berlin: Panoramastr. 1, 10178 Berlin, Germany
Office Bonn: Bachstr. 6, 53115 Bonn, Germany
Office München: Am Knie 16, 81241 München, Germany
http://www.emlix.com

emlix - your embedded Linux partner

[Jan Kiszka]

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.

[Andreas Naumann]

Am 16.12.25 um 11:53 schrieb Baurzhan Ismagulov:
<snip>

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

On our side, putting arbitrary SHAs into the kas config seems to be not
very acceptable, so
having more frequent release tags would make it easier to bump the kas
config to it and
drop patches which have already been accepted.

So quarterly releases would be an advantage for the development phase.

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

I must agree that once a product release has happened, the interest in
bumping
frequently will probably drop. However, when doing a yearly product bump, or
even only every two years, it would still be nice, to have more freedom
when to do so.

regards,
Andreas

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

[Baurzhan Ismagulov]

On 2025-12-16 12:36, 'Jan Kiszka' via isar-users wrote:
> > 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.

Ok, let me understand.

cip-core wants quarterly Isar releases -- good to know.
What is the cycle?

Do I understand correctly, if Isar would do quarterly releases, cip-core would
use Isar tags?
Then it would go downstream, Isar issues would be found and fixed (which
suggests extending Isar testsuite).
Is your point that the next Isar release a quarter later would be soon enough
for the downstreams?

In any case, we could still try 1.1 in 2026-Q3 and then revisit this topic.

With kind regards,
Baurzhan

[Jan Kiszka]

On 16.12.25 13:27, Baurzhan Ismagulov wrote:
> On 2025-12-16 12:36, 'Jan Kiszka' via isar-users wrote:
>>> 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.
>
> Ok, let me understand.
>
> cip-core wants quarterly Isar releases -- good to know.
> What is the cycle?
>
> Do I understand correctly, if Isar would do quarterly releases, cip-core would
> use Isar tags?

At least, we would try to align then. There can always be reasons to
slightly deviate in concrete case, but so far I was preferring a newer
Isar revision with local, upstream-pending hot-fixes over older Isar
revisions. That is because I know downstream will do own integration
decisions, and the more freedom isar-cip-core can provide by being
compatible with more recent Isar versions, the better.

Not too infrequently, we are also developing Isar features to cater
developments in isar-cip-core, and it is much nicer to consume them via
upstream rather than out-of-tree patches in our layer.

> Then it would go downstream, Isar issues would be found and fixed (which
> suggests extending Isar testsuite).
> Is your point that the next Isar release a quarter later would be soon enough
> for the downstreams?
>
> In any case, we could still try 1.1 in 2026-Q3 and then revisit this topic.
>

2 release per year would be an improvement, and we can try this if you
consider it a reasonable balance between stabilization effort on the one
side and community value on the other.