Hi Avik and all,
... not sure anymore in which conversation I dropped this... so repeat it
here. Hotfix releases are very similar to normal releases (in terms of
steps) except:
- we don't have to wait 2 weeks for the community to discuss the
release, because it is based on an already approved release
- ... and no revolutionary aka backwards compatibility breaking changes
are allowed
- a hotfix release should contain 1-3 ("3" is arbitrary, but sounds good
to me) pull requests
Full list of current hotfix rules here:
https://fineract.apache.org/docs/current/#_maintenance_release_process
The rest of the process (see
https://fineract.apache.org/docs/current/#_releases) would be exactly the
same. The voting process might be potentially the longest part, but if we
look back at past releases (4 or so) this usually takes only a couple
of hours (and that's only because we live in different timezones). A
release is approved by 3 PMC votes... can't remember that we had to use the
72h period in recent years.
Note: once a hotfix is out (let's 1.7.1) then it replaces the previous
minor release (1.7.0 in this example). Just to say: only the latest will be
available for download.
My 2 cents.
Cheers
On Mon, Sep 19, 2022 at 6:17 PM James Dailey <[email protected]> wrote:
> Hi Avik
>
> I'd like to check with other Apache projects to find out what they do for
> hot fixes.
>
> "A binding release vote of the PMC is the critical gating step in the
> release process. Without such a vote, the release is just a set of files
> prepared by an individual. After such a vote, it is a formal offering of
> the ASF, backed by the "full faith and credit" of the Foundation."
> https://infra.apache.org/release-publishing.html
>
> see also:
> https://blogs.apache.org/comdev/entry/how_apache_projects_use_consensus
>
> There is no "timeout" based release.
>
> Then we get to the norms of this group.
> It feels important that the most active devs have the time to comment and
> review the changelog, even if they are not on the PMC. 72 hrs may not be
> enough.
> And, as I understand it, the two weeks time frame is a sort of *norm*
> within Apache to allow people to take the necessary careful steps - run
> regression tests(?) to ensure that the new release or hotfix is free from
> defects.
>
> So, to your proposal - I would agree that in some cases, like the hotfixes
> where we have some very active devs and everyone is essentially waiting for
> the two weeks to close, that this is not that useful.
> I do agree that we should have a faster process for an urgent hotfix as
> this is intended to fix something missed during the release process.
>
> Some other options?
>
> e.g.
> 5 PMC votes and 72 hrs
> 3 PMC votes and 6 days
>
>
> Thanks
> @[email protected] <[email protected]>
>
>
>
> On Mon, Sep 19, 2022 at 7:58 AM Avik Ganguly <[email protected]> wrote:
>
>> Hello Devs & Non-Devs,
>>
>> I would like your opinion on the below points for hot fix releases :-
>>
>> - Release discussion after cutting a branch (usually this thing is 2
>> weeks open in mailing lists for feedback). Can we do something about this
>> to cut it down to as little time as possible? I would like to propose a
>> day
>> or 3 votes on whether the discussion is adequate for cutting a release.
>> - Release voting (usual rules, 3 PMC votes or 72 hours). If the
>> release discussion is passing through votes rather than timeout, would it
>> make sense in removing this step as redundant or would it be against
>> Apache
>> policy?
>>
>> With best regards,
>> Avik Ganguly.
>>
>> Disclaimer:
>>
>> Privileged & confidential information is contained in this message
>> (including all attachments). If you are not an intended recipient of this
>> message, please destroy this message immediately and kindly notify
>> the sender by reply e-mail. Any unauthorised use or dissemination of this
>> message in any manner whatsoever, in whole or in part, is strictly
>> prohibited. This e-mail, including all attachments hereto, (i) is for
>> discussion purposes only and shall not be deemed or construed to be a
>> professional opinion unless expressly stated otherwise, and (ii) is not
>> intended, written or sent to be used, and cannot and shall not be used, for
>> any unlawful purpose. This communication, including any attachments, may
>> not be free of viruses, interceptions or interference, and may not be
>> compatible with your systems. You should carry out your own virus checks
>> before opening any attachment to this e-mail. The sender of this e-mail and
>> *Fynarfin Tech Private Limited* shall not be liable for any damage that
>> you may sustain as a result of viruses, incompleteness of this message, a
>> delay in receipt of this message or computer problems experienced.
>>
>
