Re: Decide on official Isar release cycle

["'Andreas Naumann' via isar-users" <isar-users@googlegroups.com>]

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

-- 
emlix GmbH
Headquarters: Berliner Str. 12, 37073 Göttingen, Germany
Phone +49 (0)551 30664-0, e-mail info@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

-- 
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/78e2e62c-37e0-4b10-9ccf-a82937ee0368%40emlix.com.