Re: Decide on official Isar release cycle

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

Hello,

Am 16.12.25 um 09:06 schrieb 'Jan Kiszka' via isar-users:
> On 16.12.25 08:58, Anton Mikanovich wrote:
>> 16/12/2025 09:37, 'Clara Kowalsky' via isar-users 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.
>>> 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
>>>
>> 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.
> 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.

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 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/23fcde9d-f908-4daa-bcd6-ee501d6759e3%40emlix.com.