[sane-devel] Release 1.0.33?

[Povilas Kanapickas]

Hi Ralph,

On 8/18/21 5:56 PM, Ralph Little wrote:
> Hi,
> 
> On 2021-08-18 3:25 a.m., Povilas Kanapickas wrote:
>> On 8/17/21 8:11 PM, Ralph Little wrote:
>>> Hi,
>>> OK, seems like we have an appetite for a release.
>>> Since this is the first time we have done this without Olaf, I suggest
>>> that we give ourselves plenty of time to figure out the ropes.
>>>
>>> I propose the following timeline:
>>>
>>> Feature Freeze - Sept 24
>>> Code Freeze - Oct 7
>>> Release - Oct 14
>> I propose that we omit code freeze stage on Oct 7 and instead start a
>> release branch at around that time. This way the master branch continues
>> to be open for changes and we don't need to hurry to do the actual
>> release.
>>
>> I also suggest that we do one or more release candidates. This way
>> significant issues can be caught before we release to the wide public.
>>
>> My suggested timeline is this:
>>
>> Feature Freeze - Sept 24
>> Release branch created, master is open for new changes - Oct 7
>> Release-candidate released - Oct 7
>> Either the final release or a next release candidate depending on the
>> number and seriousness of new bugs filled: Every two weeks after that
>>
>> I can manage all the dance with the creation of release branches and
>> release candidates.
> 
> Since the majority of users get their releases from their distros, who
> for the most part seem pretty conservative about their SANE releases, do
> you think we would get sufficient buy-in from distros for the release
> candidates to get much exposure?
> I can certainly cut an RC release on the sane-release PPA so that people
> using that can get a taster.

A release candidate is easy to make. The primary reason for it is to
communicate that we think this release is good, so that more people have
reasons to report bugs. If there aren't bugs reported, then we wouldn't
get them if we had a feature freeze on the master branch.

> Also we would need a phase before the first release candidate is
> generated to get translations in. That could be between Sept 24 and the
> first release candidate I guess, but before we had a specific period of
> time for translation where we wouldn't be expecting to see code changes.

Could maybe the first release candidate be the point where translations
could start flowing in?

What do you think about this approach?

Thanks,
Povilas