[sane-devel] [ITR] Intent To Release: sane-backends-1.0.28

[Olaf Meeuwissen]

Hi Povilas,

Povilas Kanapickas writes:

> Hi Olaf,
>
> On 2019-06-26 16:29, Olaf Meeuwissen wrote:
>>  [2]: https://gitlab.com/sane-project/backends/-/milestones/2
>>
>> In terms of timeline, things look like this (for those of you who can't
>> be bothered to follow the link :wink:):
>>
>>   | Date       | Phase                   |
>>   |:----------:|:------------------------|
>>   | 2019-06-26 | Kick-off                |
>>   | 2019-07-10 | Feature freeze          |
>>   | 2019-07-24 | Code freeze             |
>>   | 2019-07-31 | Release :confetti_ball: |
>
> I'm wondering, would it make sense to branch off to a separate release
> branch at the beginning of the feature freeze and then apply the freeze
> only for that branch? That way the release branch would still stabilize
> yet the work on the master branch could continue.
>
> The code freeze makes most sense when branching off makes fixes harder
> as they need to be applied to two places. Ever since we moved to git
> this argument has much less weight as cherry-picking in git is very easy.
>
> Of course, this change is probably too late for this release, but we
> could perhaps consider this suggestion for the next one.

Thanks for bringing this up.  I agree with considering this for the next
one.  I'd really like to move to semantic versioning.  That way we can
make a 1.1 branch at "feature freeze" and only add bug fixes there.
Preferably via cherry-picking from master but other flows are possible.

New features can go to master any time they're ready.

Anyway, that's for later.  Let's focus on 1.0.28 now.
--
Olaf Meeuwissen, LPIC-2            FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Software                        https://my.fsf.org/donate
 Join the Free Software Foundation              https://my.fsf.org/join