On Sun, Mar 29, 2020 at 8:10 AM Abdelatif Guettouche
<abdelatif.guettou...@gmail.com> wrote:
> For this thread, I'd like if we can agree on (not only discuss) two
> things: 1. The release process. 2. The date of the first Apache
> release.
>
> 1. The release process:
> Here is some of what has been suggested before. (Most by Nathan in a
> different thread)
> 1. a) Create a release branch and keep accepting new features in
> master. Bugfixes that should be in the release are backported from
> master.
> _or_
> b) Freeze the repos, accept only critical bugfixes, new
> features would wait for the next merging window.
> The release branches and tags should follow a well defined naming
> convention. The current convention is: nuttx-major.minor (ex.
> nuttx-8.3)
> The release candidate branches or tags should append -rcX at the
> end with X being the candidate iteration.
> 2. After review and testing, create release candidate tarballs.
> 3. Start soak period (we need to determine how long the soak
> period should be) to give downstream time to find/report/fix bugs.
> 4. If necessary, backport bug fixes and issue another release candidate.
> 5. When no more showstopper issues remain, create the final
> release tarballs.
>
> 2. The release date: Sooner rather than later.
>
> Please share your thoughts on what should be in the release process.
> We will create a wiki page for that for future references.
>
> There are some extra ASF steps that we will deal with once we get the
> above sorted out.
Regarding the specific questions Abdelatif asked:
My recommendations (pending input from the community of course) are:
(1) Aim for a April 30 release.
(2) Call it NuttX 9.0.
(3) Two week soak. If showstopper issues are found, they are fixed on
master, backported to the branch, and a new release candidate is
made. Whenever this happens, make sure there is at least 1 week
remaining in the soak; if not, extend the soak by the requisite
number of days to have 1 week. E.g., if there are 3 days left in
the soak and a new release candidate is made, extend the soak 4
more days.
(4) The final release is always identical to the last release
candidate, except for removal of the -rcX in the version number.
(5) Release every two months.
(6) For each release, if API/ABI compatibility of the Core OS is
changed, or if changes to the build system require changes by the
user (as in the 8.0 release), the Major number is incremented.
Otherwise, only the Minor number is incremented.
If we do as I suggest above, then for this first release, the timeline
might look like this:
(0) Between now and April 6, make sure we have our DISCLAIMER in
order, get our mentors' feedback/advice and whether we're
forgetting some important details that will prevent our release,
and make sure our PPMC members are satisfied that their concerns
(which were raised last week) are addressed to their satisfaction.
(1) On April 6 (first Monday in April), create release branch
"nuttx-9.0", tag "nuttx-9.0-rc1", and make
"nuttx-9.0-incubating-rc1" tarball.
(2) Soak period until April 20. I recommend we post a heads-up to the
Incubator General mailing list that we are beginning our first
release and there will be a vote soon, and in that email, ask very
nicely for IPMC members to kindly overlook what we're doing, so
that we won't have nasty surprises later!!
(3) If issues found, fix on master, backport to nuttx-9.0 branch, make
new release candidate, extend soak to ensure at least 1 week
remains in soak.
(4) When no showstoppers found and no additional release candidates,
proceed to step 5.
(5) Stage the release as instructed by the Incubator PMC (see note)
and call for release vote on Incubator general list.
(6) Hopefully the IPMC approves the release!!!
ATTENTION: Please remember, this is a volunteer-driven community
process. What I wrote above is only the initial conversation starter.
Everyone is welcome, invited, and encouraged to participate in this
discussion, point out any flaws or mistakes above, make different
suggestions. Don't be shy!!
Cheers,
Nathan
