You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nuttx.apache.org by "Matias N." <ma...@imap.cc> on 2020/06/15 16:55:03 UTC
release branches/tags
Hi,
I wanted to ask about what you think is the best way of working with nuttx/apps repo for a downstream user considering the new release branching strategy.
Previously I was used to having the master branch contain release tags so I would generally work on top of these tags creating local commits on my project specific branch, inside a fork of nuttx/apps, if needed. Then, whenever a new version of NuttX was released, I could rebase my branch to the new release tag. Moreover, this local branch will usually contain a series of commits which I intend to upstream (fixes/improvements). To do so, I would create a branch stemming from master (or, at least, the most recent release tag) and then cherry-pick these commits there.
To contribute this in the form of PRs I would do this creating one branch for each PR. At the end of each PR acceptance I can then rebase my main working branch to the new tip and the rebase would recognize these upstreamed commits and would not generate any conflicts. In the end, my branch would only contain non-upstreamed commits.
Now, I'm facing a problem whereas I would like to work on top of stable releases but since these are tips of branches that are never merged back to master, rebasing as previously described introduces many conflicts between commits which are backported from master to these branches. To me it is strange that these release branches are never merged and no release tag seems to exist. Most projects I worked with usually tag release commits and they are always part of the main history.
I'm wondering if maybe there's something I could change in my workflow or maybe the release branching/tagging strategy could be adapted to ease downstream work. For example, if there would be something as a feature-freeze window some time before a release, disruptive PRs (ie: non bug fix PRs) against master could be held until master is stabilized and released with a tag. In this scenario I think release branches are not needed, the resulting history is linear and there are no unmerged tips.
Best,
Matias
Re: release branches/tags
Posted by Brennan Ashton <ba...@brennanashton.com>.
On Mon, Jun 15, 2020 at 1:21 PM Matias N. <ma...@imap.cc> wrote:
>
> The fact the the release branch was merged does not impede to continue to add commits to it. In any case, I would expect fixes to LTS releases to bump the version number, so whenever a new minor version for that LTS version is to be released and it is considered final (i.e. 9.2 if 9.x is LTS), it would be merged and tagged.
>
> Or am I missing something?
>
I am fairly sure you cannot do what you are asking and this is one of
the points people bring up against the GitFlow workflow.
Master cannot look like this:
* - V-1.0.0
| - C1
| - C2
* - V-1.1.0
| - C3
* - V-1.0.1 (Bug fix to the V1.0 release)
| - C4
This is why I recommended that you create a branch off of whatever
release you are using and then use the rebase from the base from the
tag to the head of your branch on to master or wherever you want
Something like this:
git rebase --onto nuttx-1.2 nuttx-1.0 HEAD
--Brennan
Re: release branches/tags
Posted by "Matias N." <ma...@imap.cc>.
The fact the the release branch was merged does not impede to continue to add commits to it. In any case, I would expect fixes to LTS releases to bump the version number, so whenever a new minor version for that LTS version is to be released and it is considered final (i.e. 9.2 if 9.x is LTS), it would be merged and tagged.
Or am I missing something?
On Mon, Jun 15, 2020, at 16:49, Nathan Hartman wrote:
> On Mon, Jun 15, 2020 at 3:41 PM Matias N. <ma...@imap.cc> wrote:
>
> > Functionally, yes. But git has troubles recognizing that the cherry-picked
> > commits are the same on master and generates conflicts. The merge would
> > solve this in theory, since the release branch tip would end up matching a
> > commit on master.
>
>
> Suppose in the future we wish to have LTS releases -- Long Term Support,
> where "Support" just means that the release line receives bugfix and
> security fix maintenance for a longer period of time than regular releases.
> We briefly touched on this idea recently but are not ready to do it yet.
> Nevertheless, as an example only for illustration, suppose that an LTS
> release is to be maintained for 2 years.
>
> Then, how does the strategy of merging release branches back to master
> support that type of requirement?
>
> Nathan
>
Re: release branches/tags
Posted by Nathan Hartman <ha...@gmail.com>.
On Mon, Jun 15, 2020 at 3:41 PM Matias N. <ma...@imap.cc> wrote:
> Functionally, yes. But git has troubles recognizing that the cherry-picked
> commits are the same on master and generates conflicts. The merge would
> solve this in theory, since the release branch tip would end up matching a
> commit on master.
Suppose in the future we wish to have LTS releases -- Long Term Support,
where "Support" just means that the release line receives bugfix and
security fix maintenance for a longer period of time than regular releases.
We briefly touched on this idea recently but are not ready to do it yet.
Nevertheless, as an example only for illustration, suppose that an LTS
release is to be maintained for 2 years.
Then, how does the strategy of merging release branches back to master
support that type of requirement?
Nathan
Re: release branches/tags
Posted by "Matias N." <ma...@imap.cc>.
Functionally, yes. But git has troubles recognizing that the cherry-picked commits are the same on master and generates conflicts. The merge would solve this in theory, since the release branch tip would end up matching a commit on master.
On Mon, Jun 15, 2020, at 16:31, Abdelatif Guettouche wrote:
> The release branch doesn't contain anything that's not already present
> in master. The log between the two branches (a release and master)
> are just the cherry picked commits. So there is nothing really to
> merge back.
>
>
> On Mon, Jun 15, 2020 at 7:13 PM Matias N. <ma...@imap.cc> wrote:
> >
> > As a reference, this merging back is used in GitFlow, so I guess it should work:
> > https://datasift.github.io/gitflow/IntroducingGitFlow.html
> > (see 4th figure)
> >
> > On Mon, Jun 15, 2020, at 15:09, Matias N. wrote:
> > > On Mon, Jun 15, 2020, at 15:04, Brennan Ashton wrote:
> > >> On Mon, Jun 15, 2020 at 10:47 AM Matias N. <ma...@imap.cc> wrote:
> > >> >
> > >> > There are release tags created:
> > >> > > https://github.com/apache/incubator-nuttx/releases/tag/nuttx-9.0.0-RC1
> > >> >
> > >> > I understood that as a release candidate, not a final release. Anyway, this just points to the tip of release/9.0 so it does not change my situation.
> > >> >
> > >> Sorry, this is my oversight, I probably should have tagged that commit
> > >> at nuttx-9.0.0 as well once it was approved by IPMC for release. I
> > >> will create a signed tag this evening for both os and app, but yes the
> > >> latest RC is the actual release. A bug fix release would be seen as a
> > >> tag on the same branch with the patch number increased. The reason to
> > >> rely on the tag and not the tip, is that any bug fix commit for a
> > >> patch release would also go here and have that same multi-week window
> > >> before it is released.
> > >
> > > No problem!
> > >
> > >> >
> > >> > The ability to correct bugs after a release without having to also include features that were added in between is understandable. But I don't really understand why that does not allow to merge the release branch back to master once it is considered final. Unless I'm mistaken this should not create conflicts and would only "close the loop" and let git later now how to deal with rebases between final release points easily.
> > >> >
> > >>
> > >> We can certainly give it a go on a temporary branch for this next
> > >> release and see if that makes for a better workflow and if so apply
> > >> the merge to master. We have been trying to only do fast-forward
> > >> merges, but this might be worthy of an exception to that.
> > >
> > > Cool. It is good to test on a temporary branch and see if the idea works. It would make upgrading between nuttx releases an easier process.
> > >
> > >> --Brennan
> > >>
> > >
>
Re: release branches/tags
Posted by Abdelatif Guettouche <ab...@gmail.com>.
The release branch doesn't contain anything that's not already present
in master. The log between the two branches (a release and master)
are just the cherry picked commits. So there is nothing really to
merge back.
On Mon, Jun 15, 2020 at 7:13 PM Matias N. <ma...@imap.cc> wrote:
>
> As a reference, this merging back is used in GitFlow, so I guess it should work:
> https://datasift.github.io/gitflow/IntroducingGitFlow.html
> (see 4th figure)
>
> On Mon, Jun 15, 2020, at 15:09, Matias N. wrote:
> > On Mon, Jun 15, 2020, at 15:04, Brennan Ashton wrote:
> >> On Mon, Jun 15, 2020 at 10:47 AM Matias N. <ma...@imap.cc> wrote:
> >> >
> >> > There are release tags created:
> >> > > https://github.com/apache/incubator-nuttx/releases/tag/nuttx-9.0.0-RC1
> >> >
> >> > I understood that as a release candidate, not a final release. Anyway, this just points to the tip of release/9.0 so it does not change my situation.
> >> >
> >> Sorry, this is my oversight, I probably should have tagged that commit
> >> at nuttx-9.0.0 as well once it was approved by IPMC for release. I
> >> will create a signed tag this evening for both os and app, but yes the
> >> latest RC is the actual release. A bug fix release would be seen as a
> >> tag on the same branch with the patch number increased. The reason to
> >> rely on the tag and not the tip, is that any bug fix commit for a
> >> patch release would also go here and have that same multi-week window
> >> before it is released.
> >
> > No problem!
> >
> >> >
> >> > The ability to correct bugs after a release without having to also include features that were added in between is understandable. But I don't really understand why that does not allow to merge the release branch back to master once it is considered final. Unless I'm mistaken this should not create conflicts and would only "close the loop" and let git later now how to deal with rebases between final release points easily.
> >> >
> >>
> >> We can certainly give it a go on a temporary branch for this next
> >> release and see if that makes for a better workflow and if so apply
> >> the merge to master. We have been trying to only do fast-forward
> >> merges, but this might be worthy of an exception to that.
> >
> > Cool. It is good to test on a temporary branch and see if the idea works. It would make upgrading between nuttx releases an easier process.
> >
> >> --Brennan
> >>
> >
Re: release branches/tags
Posted by "Matias N." <ma...@imap.cc>.
As a reference, this merging back is used in GitFlow, so I guess it should work:
https://datasift.github.io/gitflow/IntroducingGitFlow.html
(see 4th figure)
On Mon, Jun 15, 2020, at 15:09, Matias N. wrote:
> On Mon, Jun 15, 2020, at 15:04, Brennan Ashton wrote:
>> On Mon, Jun 15, 2020 at 10:47 AM Matias N. <ma...@imap.cc> wrote:
>> >
>> > There are release tags created:
>> > > https://github.com/apache/incubator-nuttx/releases/tag/nuttx-9.0.0-RC1
>> >
>> > I understood that as a release candidate, not a final release. Anyway, this just points to the tip of release/9.0 so it does not change my situation.
>> >
>> Sorry, this is my oversight, I probably should have tagged that commit
>> at nuttx-9.0.0 as well once it was approved by IPMC for release. I
>> will create a signed tag this evening for both os and app, but yes the
>> latest RC is the actual release. A bug fix release would be seen as a
>> tag on the same branch with the patch number increased. The reason to
>> rely on the tag and not the tip, is that any bug fix commit for a
>> patch release would also go here and have that same multi-week window
>> before it is released.
>
> No problem!
>
>> >
>> > The ability to correct bugs after a release without having to also include features that were added in between is understandable. But I don't really understand why that does not allow to merge the release branch back to master once it is considered final. Unless I'm mistaken this should not create conflicts and would only "close the loop" and let git later now how to deal with rebases between final release points easily.
>> >
>>
>> We can certainly give it a go on a temporary branch for this next
>> release and see if that makes for a better workflow and if so apply
>> the merge to master. We have been trying to only do fast-forward
>> merges, but this might be worthy of an exception to that.
>
> Cool. It is good to test on a temporary branch and see if the idea works. It would make upgrading between nuttx releases an easier process.
>
>> --Brennan
>>
>
Re: release branches/tags
Posted by "Matias N." <ma...@imap.cc>.
On Mon, Jun 15, 2020, at 15:04, Brennan Ashton wrote:
> On Mon, Jun 15, 2020 at 10:47 AM Matias N. <ma...@imap.cc> wrote:
> >
> > There are release tags created:
> > > https://github.com/apache/incubator-nuttx/releases/tag/nuttx-9.0.0-RC1
> >
> > I understood that as a release candidate, not a final release. Anyway, this just points to the tip of release/9.0 so it does not change my situation.
> >
> Sorry, this is my oversight, I probably should have tagged that commit
> at nuttx-9.0.0 as well once it was approved by IPMC for release. I
> will create a signed tag this evening for both os and app, but yes the
> latest RC is the actual release. A bug fix release would be seen as a
> tag on the same branch with the patch number increased. The reason to
> rely on the tag and not the tip, is that any bug fix commit for a
> patch release would also go here and have that same multi-week window
> before it is released.
No problem!
> >
> > The ability to correct bugs after a release without having to also include features that were added in between is understandable. But I don't really understand why that does not allow to merge the release branch back to master once it is considered final. Unless I'm mistaken this should not create conflicts and would only "close the loop" and let git later now how to deal with rebases between final release points easily.
> >
>
> We can certainly give it a go on a temporary branch for this next
> release and see if that makes for a better workflow and if so apply
> the merge to master. We have been trying to only do fast-forward
> merges, but this might be worthy of an exception to that.
Cool. It is good to test on a temporary branch and see if the idea works. It would make upgrading between nuttx releases an easier process.
> --Brennan
>
Re: release branches/tags
Posted by Brennan Ashton <ba...@brennanashton.com>.
On Mon, Jun 15, 2020 at 10:47 AM Matias N. <ma...@imap.cc> wrote:
>
> There are release tags created:
> > https://github.com/apache/incubator-nuttx/releases/tag/nuttx-9.0.0-RC1
>
> I understood that as a release candidate, not a final release. Anyway, this just points to the tip of release/9.0 so it does not change my situation.
>
Sorry, this is my oversight, I probably should have tagged that commit
at nuttx-9.0.0 as well once it was approved by IPMC for release. I
will create a signed tag this evening for both os and app, but yes the
latest RC is the actual release. A bug fix release would be seen as a
tag on the same branch with the patch number increased. The reason to
rely on the tag and not the tip, is that any bug fix commit for a
patch release would also go here and have that same multi-week window
before it is released.
>
> The ability to correct bugs after a release without having to also include features that were added in between is understandable. But I don't really understand why that does not allow to merge the release branch back to master once it is considered final. Unless I'm mistaken this should not create conflicts and would only "close the loop" and let git later now how to deal with rebases between final release points easily.
>
We can certainly give it a go on a temporary branch for this next
release and see if that makes for a better workflow and if so apply
the merge to master. We have been trying to only do fast-forward
merges, but this might be worthy of an exception to that.
--Brennan
Re: release branches/tags
Posted by "Matias N." <ma...@imap.cc>.
There are release tags created:
> https://github.com/apache/incubator-nuttx/releases/tag/nuttx-9.0.0-RC1
I understood that as a release candidate, not a final release. Anyway, this just points to the tip of release/9.0 so it does not change my situation.
> >
> > I'm wondering if maybe there's something I could change in my workflow or maybe the release branching/tagging strategy could be adapted to ease downstream work. For example, if there would be something as a feature-freeze window some time before a release, disruptive PRs (ie: non bug fix PRs) against master could be held until master is stabilized and released with a tag. In this scenario I think release branches are not needed, the resulting history is linear and there are no unmerged tips.
>
> The last release was probably not a good indicator of how far the
> release branch will deviate (there were a lot of backported fixes).
> But part of the reason it is not feasible to just merge back in is two
> fold:
> 1. We want to have these branches for bug fix releases. The last
> release did not have one, but there likely should have been one for at
> least one bug that was found related to loading binaries
> 2. With the Apache release process it takes a long time for releases
> to get out the door. Once a RC is created it is likely 1-2 weeks
> before it is actually released. There are two three day voting periods
> and for example the last release one of those voting periods took a
> week. We also had to do 2 release candidates each time we do that the
> clock gets reset. In the mean time a lot of changes are happening in
> master, even today just after the release branch was created a lot of
> large changes went into master.
The ability to correct bugs after a release without having to also include features that were added in between is understandable. But I don't really understand why that does not allow to merge the release branch back to master once it is considered final. Unless I'm mistaken this should not create conflicts and would only "close the loop" and let git later now how to deal with rebases between final release points easily.
Going back to the alternative workflow of the feature-freeze window, you could also work on a separate "staging branch" instead of on master until a release is deemed final, where all disruptive PRs are collected. Then, once the latest release is deemed final, you can safely merge staging to master.
In any case, what I suggested (regardless of the chosen workflow) is to not leave unmerged branches.
>
> What I suspect would actually work well is to change your rebase
> strategy to instead of rebasing your entire branch (off of release
> branch), but instead to rebase only your commits onto master or the
> next release branch:
> git rebase --onto dest first_commit last_commit
>
> With this you would exclude all of the backport commits which are
> likely the source of the rebase troubles.
>
> I hope that helps.
>
> --Brennan
>
I guess that would work. It is a bit more painful and manual but I guess I will try that next time if release branches stay unmerged. Thanks for the suggestion.
Best,
Matias
Re: release branches/tags
Posted by Brennan Ashton <ba...@brennanashton.com>.
On Mon, Jun 15, 2020 at 9:55 AM Matias N. <ma...@imap.cc> wrote:
>
> Hi,
> I wanted to ask about what you think is the best way of working with nuttx/apps repo for a downstream user considering the new release branching strategy.
>
> Previously I was used to having the master branch contain release tags so I would generally work on top of these tags creating local commits on my project specific branch, inside a fork of nuttx/apps, if needed. Then, whenever a new version of NuttX was released, I could rebase my branch to the new release tag. Moreover, this local branch will usually contain a series of commits which I intend to upstream (fixes/improvements). To do so, I would create a branch stemming from master (or, at least, the most recent release tag) and then cherry-pick these commits there.
> To contribute this in the form of PRs I would do this creating one branch for each PR. At the end of each PR acceptance I can then rebase my main working branch to the new tip and the rebase would recognize these upstreamed commits and would not generate any conflicts. In the end, my branch would only contain non-upstreamed commits.
>
> Now, I'm facing a problem whereas I would like to work on top of stable releases but since these are tips of branches that are never merged back to master, rebasing as previously described introduces many conflicts between commits which are backported from master to these branches. To me it is strange that these release branches are never merged and no release tag seems to exist. Most projects I worked with usually tag release commits and they are always part of the main history.
There are release tags created:
https://github.com/apache/incubator-nuttx/releases/tag/nuttx-9.0.0-RC1
>
> I'm wondering if maybe there's something I could change in my workflow or maybe the release branching/tagging strategy could be adapted to ease downstream work. For example, if there would be something as a feature-freeze window some time before a release, disruptive PRs (ie: non bug fix PRs) against master could be held until master is stabilized and released with a tag. In this scenario I think release branches are not needed, the resulting history is linear and there are no unmerged tips.
The last release was probably not a good indicator of how far the
release branch will deviate (there were a lot of backported fixes).
But part of the reason it is not feasible to just merge back in is two
fold:
1. We want to have these branches for bug fix releases. The last
release did not have one, but there likely should have been one for at
least one bug that was found related to loading binaries
2. With the Apache release process it takes a long time for releases
to get out the door. Once a RC is created it is likely 1-2 weeks
before it is actually released. There are two three day voting periods
and for example the last release one of those voting periods took a
week. We also had to do 2 release candidates each time we do that the
clock gets reset. In the mean time a lot of changes are happening in
master, even today just after the release branch was created a lot of
large changes went into master.
What I suspect would actually work well is to change your rebase
strategy to instead of rebasing your entire branch (off of release
branch), but instead to rebase only your commits onto master or the
next release branch:
git rebase --onto dest first_commit last_commit
With this you would exclude all of the backport commits which are
likely the source of the rebase troubles.
I hope that helps.
--Brennan