Hi all,
What do you think of this guidelines?
https://github.com/geonetwork/core-geonetwork/wiki/Git-merge-branching-good-practices
Are they clear enough? Maybe I should add more pictures?
Do you want to change something?
hi María,
can you explain the reasoning behind never merging from master to your branch ?
There may be situations where your branch is not very short-lived, for example because it is a lot of work, or because the client funding the project pushes integration to the end.
Compare with e.g. this model http://nvie.com/posts/a-successful-git-branching-model/.
Kind regards,
Heikki Doeleman
On Tue, Jun 4, 2013 at 9:46 AM, María Arias de Reyna <delawen@anonymised.com> wrote:
Hi all,
What do you think of this guidelines?
https://github.com/geonetwork/core-geonetwork/wiki/Git-merge-branching-good-practicesAre they clear enough? Maybe I should add more pictures?
Do you want to change something?
How ServiceNow helps IT people transform IT departments:
- A cloud service to automate IT design, transition and operations
- Dashboards that offer high-level views of enterprise services
- A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
On Tue, Jun 4, 2013 at 11:29 AM, heikki <tropicano@anonymised.com> wrote:
hi María,
can you explain the reasoning behind never merging from master to your
branch ?
Well, maybe it is not well explained.
If your branch is based on master, then you can merge from master.
If your branch is based on a specific version branch, then you should
only merge from that specific version branch.
The idea is that every feature is commited only once, so we don't have
two different commits with the same info on all geonetwork branch
network. We should avoid doing one commit to master and another
different commit to another branch but with the same changes (like we
are doing now with cherry picks). Because, then (if we have two
different commits with the same changes), branches will never be
easily merged again.
If we do it like described, we will always have "automatic pull
request merging" (or almost) (or, at least, less complicated merging
on pull request) because there will be no duplicated commits that will
collided.
There may be situations where your branch is not very short-lived, for
example because it is a lot of work, or because the client funding the
project pushes integration to the end.Compare with e.g. this model
http://nvie.com/posts/a-successful-git-branching-model/.
That is the model I'm trying to describe. Will change it again 
Kind regards,
Heikki DoelemanOn Tue, Jun 4, 2013 at 9:46 AM, María Arias de Reyna <delawen@anonymised.com>
wrote:Hi all,
What do you think of this guidelines?
https://github.com/geonetwork/core-geonetwork/wiki/Git-merge-branching-good-practices
Are they clear enough? Maybe I should add more pictures?
Do you want to change something?
------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j
_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at
http://sourceforge.net/projects/geonetwork
OK, in that case, I think it is not that clear indeed. As I read the model described on nvie.com, the master branch only contains commits from the very end of release branches – so, on master, there are only releases. There is a ‘development’ branch in that model which has the role that up to now, we used for the master branch for. So this is quite a change to the way we deal with this.
On Tue, Jun 4, 2013 at 11:34 AM, María Arias de Reyna <delawen@anonymised.com> wrote:
On Tue, Jun 4, 2013 at 11:29 AM, heikki <tropicano@anonymised.com> wrote:
hi María,
can you explain the reasoning behind never merging from master to your
branch ?Well, maybe it is not well explained.
If your branch is based on master, then you can merge from master.
If your branch is based on a specific version branch, then you should
only merge from that specific version branch.The idea is that every feature is commited only once, so we don’t have
two different commits with the same info on all geonetwork branch
network. We should avoid doing one commit to master and another
different commit to another branch but with the same changes (like we
are doing now with cherry picks). Because, then (if we have two
different commits with the same changes), branches will never be
easily merged again.If we do it like described, we will always have “automatic pull
request merging” (or almost) (or, at least, less complicated merging
on pull request) because there will be no duplicated commits that will
collided.There may be situations where your branch is not very short-lived, for
example because it is a lot of work, or because the client funding the
project pushes integration to the end.Compare with e.g. this model
http://nvie.com/posts/a-successful-git-branching-model/.That is the model I’m trying to describe. Will change it again
Kind regards,
Heikki DoelemanOn Tue, Jun 4, 2013 at 9:46 AM, María Arias de Reyna <delawen@anonymised.com>
wrote:Hi all,
What do you think of this guidelines?
https://github.com/geonetwork/core-geonetwork/wiki/Git-merge-branching-good-practices
Are they clear enough? Maybe I should add more pictures?
Do you want to change something?
How ServiceNow helps IT people transform IT departments:
- A cloud service to automate IT design, transition and operations
- Dashboards that offer high-level views of enterprise services
- A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at
http://sourceforge.net/projects/geonetwork
On Tue, Jun 4, 2013 at 11:44 AM, heikki <tropicano@anonymised.com> wrote:
OK, in that case, I think it is not that clear indeed. As I read the model
described on nvie.com, the master branch only contains commits from the very
end of release branches -- so, on master, there are only releases. There is
a 'development' branch in that model which has the role that up to now, we
used for the master branch for. So this is quite a change to the way we deal
with this.
Well, that's one of the differences on our model and theirs, but the
fluxes of commits are the same. You see, their master never drags
"unstable" features to the branch version.
Let me go a bit further with the explanation:
If our master is "unstable", then it will have several features that
are not intended to go to a stable branch yet.
If you intend to develop for the next stable version, you should
develop for that stable version.
If you intend to develop for something on a long run, you should
develop on the unstable version. But then be clear that it will never
be on the stable version, as any merging from "unstable" (master) o
"stable" will drag lots of other "unstable" features to "stable".
If you are not sure which version you are going to merge, and maybe it
will be on the next "stable" version, then you can develop based on
that "stable" version. If you are not on time to put your feature on
"stable", you can always merge back to master "unstable". Doing
otherwise (from "unstable" master to "stable") will be impossible (or
very dirty and breacking the flux).
More clear?
On Tue, Jun 4, 2013 at 11:49 AM, María Arias de Reyna <delawen@anonymised.com> wrote:
On Tue, Jun 4, 2013 at 11:44 AM, heikki <tropicano@anonymised.com> wrote:
OK, in that case, I think it is not that clear indeed. As I read the model
described on nvie.com, the master branch only contains commits from the very
end of release branches -- so, on master, there are only releases. There is
a 'development' branch in that model which has the role that up to now, we
used for the master branch for. So this is quite a change to the way we deal
with this.Well, that's one of the differences on our model and theirs, but the
fluxes of commits are the same. You see, their master never drags
"unstable" features to the branch version.Let me go a bit further with the explanation:
If our master is "unstable", then it will have several features that
are not intended to go to a stable branch yet.If you intend to develop for the next stable version, you should
develop for that stable version.
If you intend to develop for something on a long run, you should
develop on the unstable version. But then be clear that it will never
be on the stable version, as any merging from "unstable" (master) o
"stable" will drag lots of other "unstable" features to "stable".If you are not sure which version you are going to merge, and maybe it
will be on the next "stable" version, then you can develop based on
that "stable" version. If you are not on time to put your feature on
"stable", you can always merge back to master "unstable". Doing
otherwise (from "unstable" master to "stable") will be impossible (or
very dirty and breacking the flux).More clear?
All this discussion came alive here on Bolsena. We are not happy with
how merging works now (it requires lots of time and efforts) so we are
trying to change the way we work.
Not in time for 2.10, but for future versions.
yes, I gathered that.
Still not that clear though, see comments inline.
Why not just use that mode on nvie.com as it is? It’s very clear to me, and is already described, with diagram and all.
On Tue, Jun 4, 2013 at 11:51 AM, María Arias de Reyna <delawen@anonymised.com> wrote:
On Tue, Jun 4, 2013 at 11:49 AM, María Arias de Reyna <delawen@anonymised.com31…> wrote:
On Tue, Jun 4, 2013 at 11:44 AM, heikki <tropicano@anonymised.com> wrote:
OK, in that case, I think it is not that clear indeed. As I read the model
described on nvie.com, the master branch only contains commits from the very
end of release branches – so, on master, there are only releases. There is
a ‘development’ branch in that model which has the role that up to now, we
used for the master branch for. So this is quite a change to the way we deal
with this.Well, that’s one of the differences on our model and theirs, but the
fluxes of commits are the same. You see, their master never drags
“unstable” features to the branch version.Let me go a bit further with the explanation:
If our master is “unstable”, then it will have several features that
are not intended to go to a stable branch yet.
So when do you merge to master, instead of a a stable branch (those’d be like 2.6.x, right?). How to determine whether our master is “stable” or not ?
If you intend to develop for the next stable version, you should
develop for that stable version.
Currently we do not make ‘stable’ branches until a next major release is entering the RC program. E.g., 2.10.x did not exist from at least the moment that 2.8.0 was released. So if you want to develop for the next stable release, should you do it on master ? But any commit to master that’s not gone through a QA like the RC process, makes master unstable.
If you intend to develop for something on a long run, you should
develop on the unstable version. But then be clear that it will never
be on the stable version, as any merging from “unstable” (master) o
“stable” will drag lots of other “unstable” features to “stable”.
So master is “the unstable version” ? So if you develop something on the long run, you should commit to master, meaning it will never go to a stable version ? That seems unclear too. Of course at some point in time you want it to go to some stable version.
If you are not sure which version you are going to merge, and maybe it
will be on the next “stable” version, then you can develop based on
that “stable” version. If you are not on time to put your feature on
“stable”, you can always merge back to master “unstable”. Doing
otherwise (from “unstable” master to “stable”) will be impossible (or
very dirty and breacking the flux).More clear?
Still I think maybe it is more clear to just use the nvie.com mode as it is…
All this discussion came alive here on Bolsena. We are not happy with
how merging works now (it requires lots of time and efforts) so we are
trying to change the way we work.Not in time for 2.10, but for future versions.
Ok, let's wait to hear more voices (more comments inline).
On Tue, Jun 4, 2013 at 11:58 AM, heikki <tropicano@anonymised.com> wrote:
On Tue, Jun 4, 2013 at 11:51 AM, María Arias de Reyna <delawen@anonymised.com>
wrote:On Tue, Jun 4, 2013 at 11:49 AM, María Arias de Reyna <delawen@anonymised.com.>
wrote:
> On Tue, Jun 4, 2013 at 11:44 AM, heikki <tropicano@anonymised.com> wrote:
> Let me go a bit further with the explanation:
>
> If our master is "unstable", then it will have several features that
> are not intended to go to a stable branch yet.So when do you merge to master, instead of a a stable branch (those'd be
like 2.6.x, right?). How to determine whether our master is "stable" or not
?
As I see it, master itself will never be completely stable, unless we
put all our efforts stabilizing it and not creating new features until
it is stable. But I think it is, more or less, how we work right now.
Currently we do not make 'stable' branches until a next major release is
entering the RC program. E.g., 2.10.x did not exist from at least the moment
that 2.8.0 was released. So if you want to develop for the next stable
release, should you do it on master ? But any commit to master that's not
gone through a QA like the RC process, makes master unstable.
In my opinion everything too experimental (very unstable) shouldn't be
in master. Anything unstable/being tested can be on master.
As I understand, right now, when we want to create a new version, we
pick master and stabilize it, right? So the process is not changed on
this part.
So master *is* "the unstable version" ? So if you develop something on the
long run, you should commit to master, meaning it will never go to a stable
version ? That seems unclear too. Of course at some point in time you want
it to go to some stable version.
Every new 2.y.x will start as master, so anything committed to master
before that is already there.
Right now, master is our unstable version, as I understand it. Maybe
because I am thinking on the "unstable" definition of Debian, which is
"almost stable but still needs testing".
Still I think maybe it is more clear to just use the nvie.com mode as it
is...
We can do it.
Maybe we should change vocab a little bit. “Stable branch” I think is a misnomer. The 2.y.x branches are better referred to as “release branches”, as any new commits to those will make them unstable too. There’s no such thing as a stable branch (except in nvie.com’s model where master is stable).
OK let’s see if other people have opinions. For the moment I’m still of the opinion that this http://nvie.com/posts/a-successful-git-branching-model/ looks good as it is…
On Tue, Jun 4, 2013 at 12:06 PM, María Arias de Reyna <delawen@anonymised.com> wrote:
Ok, let’s wait to hear more voices (more comments inline).
On Tue, Jun 4, 2013 at 11:58 AM, heikki <tropicano@anonymised.com> wrote:
On Tue, Jun 4, 2013 at 11:51 AM, María Arias de Reyna <delawen@anonymised.com>
wrote:On Tue, Jun 4, 2013 at 11:49 AM, María Arias de Reyna <delawen@anonymised.com>
wrote:On Tue, Jun 4, 2013 at 11:44 AM, heikki <tropicano@anonymised.com> wrote:
Let me go a bit further with the explanation:
If our master is “unstable”, then it will have several features that
are not intended to go to a stable branch yet.So when do you merge to master, instead of a a stable branch (those’d be
like 2.6.x, right?). How to determine whether our master is “stable” or not
?As I see it, master itself will never be completely stable, unless we
put all our efforts stabilizing it and not creating new features until
it is stable. But I think it is, more or less, how we work right now.Currently we do not make ‘stable’ branches until a next major release is
entering the RC program. E.g., 2.10.x did not exist from at least the moment
that 2.8.0 was released. So if you want to develop for the next stable
release, should you do it on master ? But any commit to master that’s not
gone through a QA like the RC process, makes master unstable.In my opinion everything too experimental (very unstable) shouldn’t be
in master. Anything unstable/being tested can be on master.As I understand, right now, when we want to create a new version, we
pick master and stabilize it, right? So the process is not changed on
this part.So master is “the unstable version” ? So if you develop something on the
long run, you should commit to master, meaning it will never go to a stable
version ? That seems unclear too. Of course at some point in time you want
it to go to some stable version.Every new 2.y.x will start as master, so anything committed to master
before that is already there.Right now, master is our unstable version, as I understand it. Maybe
because I am thinking on the “unstable” definition of Debian, which is
“almost stable but still needs testing”.Still I think maybe it is more clear to just use the nvie.com mode as it
is…We can do it.
One more remark: “The leading principal is that master branch (trunk in SVN) has all the commits and the branches of the specific versions are a subset of commits.”
Maybe usually true, but it cannot in general be true. For example, suppose the we support a version of Java in 2.y.x where there does not exist an ideal way to do something, so we do it in a less-than-ideal way. In 2.y+1.x we support a later version of Java, replacing the less than ideal code with a better solution. Then in the proposed model, we will be maintaining both solutions, one in 2.y.x and one in later branches + master, no?
This is actually the case in one place (Jeeves TransformerFactoryFactory.java, where the 1.5 code is still active by the way, but the 1.6 code sits ready in comments).
On Tue, Jun 4, 2013 at 12:11 PM, heikki <tropicano@anonymised.com> wrote:
Maybe we should change vocab a little bit. “Stable branch” I think is a misnomer. The 2.y.x branches are better referred to as “release branches”, as any new commits to those will make them unstable too. There’s no such thing as a stable branch (except in nvie.com’s model where master is stable).
OK let’s see if other people have opinions. For the moment I’m still of the opinion that this http://nvie.com/posts/a-successful-git-branching-model/ looks good as it is…
On Tue, Jun 4, 2013 at 12:06 PM, María Arias de Reyna <delawen@anonymised.com> wrote:
Ok, let’s wait to hear more voices (more comments inline).
On Tue, Jun 4, 2013 at 11:58 AM, heikki <tropicano@anonymised.com> wrote:
On Tue, Jun 4, 2013 at 11:51 AM, María Arias de Reyna <delawen@anonymised.com>
wrote:On Tue, Jun 4, 2013 at 11:49 AM, María Arias de Reyna <delawen@anonymised.com>
wrote:On Tue, Jun 4, 2013 at 11:44 AM, heikki <tropicano@anonymised.com> wrote:
Let me go a bit further with the explanation:
If our master is “unstable”, then it will have several features that
are not intended to go to a stable branch yet.So when do you merge to master, instead of a a stable branch (those’d be
like 2.6.x, right?). How to determine whether our master is “stable” or not
?As I see it, master itself will never be completely stable, unless we
put all our efforts stabilizing it and not creating new features until
it is stable. But I think it is, more or less, how we work right now.Currently we do not make ‘stable’ branches until a next major release is
entering the RC program. E.g., 2.10.x did not exist from at least the moment
that 2.8.0 was released. So if you want to develop for the next stable
release, should you do it on master ? But any commit to master that’s not
gone through a QA like the RC process, makes master unstable.In my opinion everything too experimental (very unstable) shouldn’t be
in master. Anything unstable/being tested can be on master.As I understand, right now, when we want to create a new version, we
pick master and stabilize it, right? So the process is not changed on
this part.So master is “the unstable version” ? So if you develop something on the
long run, you should commit to master, meaning it will never go to a stable
version ? That seems unclear too. Of course at some point in time you want
it to go to some stable version.Every new 2.y.x will start as master, so anything committed to master
before that is already there.Right now, master is our unstable version, as I understand it. Maybe
because I am thinking on the “unstable” definition of Debian, which is
“almost stable but still needs testing”.Still I think maybe it is more clear to just use the nvie.com mode as it
is…We can do it.
On Tue, Jun 4, 2013 at 12:31 PM, heikki <tropicano@anonymised.com> wrote:
One more remark: "The leading principal is that master branch (trunk in SVN)
has all the commits and the branches of the specific versions are a subset
of commits."Maybe usually true, but it cannot in general be true. For example, suppose
the we support a version of Java in 2.y.x where there does not exist an
ideal way to do something, so we do it in a less-than-ideal way. In 2.y+1.x
we support a later version of Java, replacing the less than ideal code with
a better solution. Then in the proposed model, we *will* be maintaining both
solutions, one in 2.y.x and one in later branches + master, no?This is actually the case in one place (Jeeves
TransformerFactoryFactory.java, where the 1.5 code is still active by the
way, but the 1.6 code sits ready in comments).
I'm not sure I understand the case.
We did some development in version X. Then we improved the development
in version X+1. As version X+1 was released after version X, then...
where is the problem? Master will contain version X when version X is
released and then some commits later it will contain X+1 version, when
merged.
On Tue, Jun 4, 2013 at 12:11 PM, heikki <tropicano@anonymised.com> wrote:
Maybe we should change vocab a little bit. "Stable branch" I think is a
misnomer. The 2.y.x branches are better referred to as "release branches",
as any new commits to those will make them unstable too. There's no such
thing as a stable branch (except in nvie.com's model where master is
stable).OK let's see if other people have opinions. For the moment I'm still of
the opinion that this
http://nvie.com/posts/a-successful-git-branching-model/ looks good as it
is...On Tue, Jun 4, 2013 at 12:06 PM, María Arias de Reyna <delawen@anonymised.com.>
wrote:Ok, let's wait to hear more voices (more comments inline).
On Tue, Jun 4, 2013 at 11:58 AM, heikki <tropicano@anonymised.com> wrote:
>
> On Tue, Jun 4, 2013 at 11:51 AM, María Arias de Reyna
> <delawen@anonymised.com>
> wrote:
>>
>> On Tue, Jun 4, 2013 at 11:49 AM, María Arias de Reyna
>> <delawen@anonymised.com>
>> wrote:
>> > On Tue, Jun 4, 2013 at 11:44 AM, heikki <tropicano@anonymised.com> wrote:
>> > Let me go a bit further with the explanation:
>> >
>> > If our master is "unstable", then it will have several features that
>> > are not intended to go to a stable branch yet.
>
>
> So when do you merge to master, instead of a a stable branch (those'd
> be
> like 2.6.x, right?). How to determine whether our master is "stable" or
> not
> ?As I see it, master itself will never be completely stable, unless we
put all our efforts stabilizing it and not creating new features until
it is stable. But I think it is, more or less, how we work right now.> Currently we do not make 'stable' branches until a next major release
> is
> entering the RC program. E.g., 2.10.x did not exist from at least the
> moment
> that 2.8.0 was released. So if you want to develop for the next stable
> release, should you do it on master ? But any commit to master that's
> not
> gone through a QA like the RC process, makes master unstable.In my opinion everything too experimental (very unstable) shouldn't be
in master. Anything unstable/being tested can be on master.As I understand, right now, when we want to create a new version, we
pick master and stabilize it, right? So the process is not changed on
this part.> So master *is* "the unstable version" ? So if you develop something on
> the
> long run, you should commit to master, meaning it will never go to a
> stable
> version ? That seems unclear too. Of course at some point in time you
> want
> it to go to some stable version.Every new 2.y.x will start as master, so anything committed to master
before that is already there.Right now, master is our unstable version, as I understand it. Maybe
because I am thinking on the "unstable" definition of Debian, which is
"almost stable but still needs testing".> Still I think maybe it is more clear to just use the nvie.com mode as
> it
> is...
>We can do it.
As I read understood the principle, master supposedly is a superset of all branches. But release branches never die; so in my example, we would have solution A in branch 2.y.x, and solution B in 2.y+1.x, and they cannot both be in master.
On Tue, Jun 4, 2013 at 12:44 PM, María Arias de Reyna <delawen@anonymised.com> wrote:
On Tue, Jun 4, 2013 at 12:31 PM, heikki <tropicano@anonymised.com> wrote:
One more remark: “The leading principal is that master branch (trunk in SVN)
has all the commits and the branches of the specific versions are a subset
of commits.”Maybe usually true, but it cannot in general be true. For example, suppose
the we support a version of Java in 2.y.x where there does not exist an
ideal way to do something, so we do it in a less-than-ideal way. In 2.y+1.x
we support a later version of Java, replacing the less than ideal code with
a better solution. Then in the proposed model, we will be maintaining both
solutions, one in 2.y.x and one in later branches + master, no?This is actually the case in one place (Jeeves
TransformerFactoryFactory.java, where the 1.5 code is still active by the
way, but the 1.6 code sits ready in comments).I’m not sure I understand the case.
We did some development in version X. Then we improved the development
in version X+1. As version X+1 was released after version X, then…
where is the problem? Master will contain version X when version X is
released and then some commits later it will contain X+1 version, when
merged.On Tue, Jun 4, 2013 at 12:11 PM, heikki <tropicano@anonymised.com> wrote:
Maybe we should change vocab a little bit. “Stable branch” I think is a
misnomer. The 2.y.x branches are better referred to as “release branches”,
as any new commits to those will make them unstable too. There’s no such
thing as a stable branch (except in nvie.com’s model where master is
stable).OK let’s see if other people have opinions. For the moment I’m still of
the opinion that this
http://nvie.com/posts/a-successful-git-branching-model/ looks good as it
is…On Tue, Jun 4, 2013 at 12:06 PM, María Arias de Reyna <delawen@anonymised.com>
wrote:Ok, let’s wait to hear more voices (more comments inline).
On Tue, Jun 4, 2013 at 11:58 AM, heikki <tropicano@anonymised.com> wrote:
On Tue, Jun 4, 2013 at 11:51 AM, María Arias de Reyna
<delawen@anonymised.com>
wrote:On Tue, Jun 4, 2013 at 11:49 AM, María Arias de Reyna
<delawen@anonymised.com…>
wrote:On Tue, Jun 4, 2013 at 11:44 AM, heikki <tropicano@anonymised.com> wrote:
Let me go a bit further with the explanation:If our master is “unstable”, then it will have several features that
are not intended to go to a stable branch yet.So when do you merge to master, instead of a a stable branch (those’d
be
like 2.6.x, right?). How to determine whether our master is “stable” or
not
?As I see it, master itself will never be completely stable, unless we
put all our efforts stabilizing it and not creating new features until
it is stable. But I think it is, more or less, how we work right now.Currently we do not make ‘stable’ branches until a next major release
is
entering the RC program. E.g., 2.10.x did not exist from at least the
moment
that 2.8.0 was released. So if you want to develop for the next stable
release, should you do it on master ? But any commit to master that’s
not
gone through a QA like the RC process, makes master unstable.In my opinion everything too experimental (very unstable) shouldn’t be
in master. Anything unstable/being tested can be on master.As I understand, right now, when we want to create a new version, we
pick master and stabilize it, right? So the process is not changed on
this part.So master is “the unstable version” ? So if you develop something on
the
long run, you should commit to master, meaning it will never go to a
stable
version ? That seems unclear too. Of course at some point in time you
want
it to go to some stable version.Every new 2.y.x will start as master, so anything committed to master
before that is already there.Right now, master is our unstable version, as I understand it. Maybe
because I am thinking on the “unstable” definition of Debian, which is
“almost stable but still needs testing”.Still I think maybe it is more clear to just use the nvie.com mode as
it
is…We can do it.
On Tue, Jun 4, 2013 at 12:47 PM, heikki <tropicano@anonymised.com> wrote:
As I read understood the principle, master supposedly is a superset of all
branches. But release branches never die; so in my example, we would have
solution A in branch 2.y.x, and solution B in 2.y+1.x, and they cannot both
be in master.
After freezing a release version, it would be merged again to master,
so changes on that version will be available for later versions.
If one version overwrites another one, the latest one will prevail (as
in all mergings should be).
On Tue, Jun 4, 2013 at 12:44 PM, María Arias de Reyna <delawen@anonymised.com>
wrote:On Tue, Jun 4, 2013 at 12:31 PM, heikki <tropicano@anonymised.com> wrote:
> One more remark: "The leading principal is that master branch (trunk in
> SVN)
> has all the commits and the branches of the specific versions are a
> subset
> of commits."
>
> Maybe usually true, but it cannot in general be true. For example,
> suppose
> the we support a version of Java in 2.y.x where there does not exist an
> ideal way to do something, so we do it in a less-than-ideal way. In
> 2.y+1.x
> we support a later version of Java, replacing the less than ideal code
> with
> a better solution. Then in the proposed model, we *will* be maintaining
> both
> solutions, one in 2.y.x and one in later branches + master, no?
>
> This is actually the case in one place (Jeeves
> TransformerFactoryFactory.java, where the 1.5 code is still active by
> the
> way, but the 1.6 code sits ready in comments).
>
>I'm not sure I understand the case.
We did some development in version X. Then we improved the development
in version X+1. As version X+1 was released after version X, then...
where is the problem? Master will contain version X when version X is
released and then some commits later it will contain X+1 version, when
merged.>
> On Tue, Jun 4, 2013 at 12:11 PM, heikki <tropicano@anonymised.com> wrote:
>>
>> Maybe we should change vocab a little bit. "Stable branch" I think is a
>> misnomer. The 2.y.x branches are better referred to as "release
>> branches",
>> as any new commits to those will make them unstable too. There's no
>> such
>> thing as a stable branch (except in nvie.com's model where master is
>> stable).
>>
>> OK let's see if other people have opinions. For the moment I'm still of
>> the opinion that this
>> http://nvie.com/posts/a-successful-git-branching-model/ looks good as
>> it
>> is...
>>
>>
>>
>>
>> On Tue, Jun 4, 2013 at 12:06 PM, María Arias de Reyna
>> <delawen@anonymised.com>
>> wrote:
>>>
>>> Ok, let's wait to hear more voices (more comments inline).
>>>
>>> On Tue, Jun 4, 2013 at 11:58 AM, heikki <tropicano@anonymised.com> wrote:
>>> >
>>> > On Tue, Jun 4, 2013 at 11:51 AM, María Arias de Reyna
>>> > <delawen@anonymised.com>
>>> > wrote:
>>> >>
>>> >> On Tue, Jun 4, 2013 at 11:49 AM, María Arias de Reyna
>>> >> <delawen@anonymised.com>
>>> >> wrote:
>>> >> > On Tue, Jun 4, 2013 at 11:44 AM, heikki <tropicano@anonymised.com>
>>> >> > wrote:
>>> >> > Let me go a bit further with the explanation:
>>> >> >
>>> >> > If our master is "unstable", then it will have several features
>>> >> > that
>>> >> > are not intended to go to a stable branch yet.
>>> >
>>> >
>>> > So when do you merge to master, instead of a a stable branch
>>> > (those'd
>>> > be
>>> > like 2.6.x, right?). How to determine whether our master is "stable"
>>> > or
>>> > not
>>> > ?
>>>
>>> As I see it, master itself will never be completely stable, unless we
>>> put all our efforts stabilizing it and not creating new features until
>>> it is stable. But I think it is, more or less, how we work right now.
>>>
>>> > Currently we do not make 'stable' branches until a next major
>>> > release
>>> > is
>>> > entering the RC program. E.g., 2.10.x did not exist from at least
>>> > the
>>> > moment
>>> > that 2.8.0 was released. So if you want to develop for the next
>>> > stable
>>> > release, should you do it on master ? But any commit to master
>>> > that's
>>> > not
>>> > gone through a QA like the RC process, makes master unstable.
>>>
>>> In my opinion everything too experimental (very unstable) shouldn't be
>>> in master. Anything unstable/being tested can be on master.
>>>
>>> As I understand, right now, when we want to create a new version, we
>>> pick master and stabilize it, right? So the process is not changed on
>>> this part.
>>>
>>> > So master *is* "the unstable version" ? So if you develop something
>>> > on
>>> > the
>>> > long run, you should commit to master, meaning it will never go to a
>>> > stable
>>> > version ? That seems unclear too. Of course at some point in time
>>> > you
>>> > want
>>> > it to go to some stable version.
>>>
>>> Every new 2.y.x will start as master, so anything committed to master
>>> before that is already there.
>>>
>>> Right now, master is our unstable version, as I understand it. Maybe
>>> because I am thinking on the "unstable" definition of Debian, which is
>>> "almost stable but still needs testing".
>>>
>>> > Still I think maybe it is more clear to just use the nvie.com mode
>>> > as
>>> > it
>>> > is...
>>> >
>>>
>>> We can do it.
>>
>>
>
I don’t understand your answer…
Even after a release, a release branch remains alive; so for example after we released 2.6.0, the branch 2.6.x remains alive and kicking to this day (if only so we can do emergency fixes to the 2.6 lineage). Same for 2.8.x and 2.10.x.
So now suppose that we changed solution A to solution B in 2.8.0. Then solution B is in 2.8.x and subsequent branches, and in master. Solution A is no longer in master. Therefore master is not a subset of all branches.
On Tue, Jun 4, 2013 at 12:48 PM, María Arias de Reyna <delawen@anonymised.com> wrote:
On Tue, Jun 4, 2013 at 12:47 PM, heikki <tropicano@anonymised.com> wrote:
As I read understood the principle, master supposedly is a superset of all
branches. But release branches never die; so in my example, we would have
solution A in branch 2.y.x, and solution B in 2.y+1.x, and they cannot both
be in master.After freezing a release version, it would be merged again to master,
so changes on that version will be available for later versions.If one version overwrites another one, the latest one will prevail (as
in all mergings should be).On Tue, Jun 4, 2013 at 12:44 PM, María Arias de Reyna <delawen@anonymised.com>
wrote:On Tue, Jun 4, 2013 at 12:31 PM, heikki <tropicano@anonymised.com> wrote:
One more remark: “The leading principal is that master branch (trunk in
SVN)
has all the commits and the branches of the specific versions are a
subset
of commits.”Maybe usually true, but it cannot in general be true. For example,
suppose
the we support a version of Java in 2.y.x where there does not exist an
ideal way to do something, so we do it in a less-than-ideal way. In
2.y+1.x
we support a later version of Java, replacing the less than ideal code
with
a better solution. Then in the proposed model, we will be maintaining
both
solutions, one in 2.y.x and one in later branches + master, no?This is actually the case in one place (Jeeves
TransformerFactoryFactory.java, where the 1.5 code is still active by
the
way, but the 1.6 code sits ready in comments).I’m not sure I understand the case.
We did some development in version X. Then we improved the development
in version X+1. As version X+1 was released after version X, then…
where is the problem? Master will contain version X when version X is
released and then some commits later it will contain X+1 version, when
merged.On Tue, Jun 4, 2013 at 12:11 PM, heikki <tropicano@anonymised.com> wrote:
Maybe we should change vocab a little bit. “Stable branch” I think is a
misnomer. The 2.y.x branches are better referred to as “release
branches”,
as any new commits to those will make them unstable too. There’s no
such
thing as a stable branch (except in nvie.com’s model where master is
stable).OK let’s see if other people have opinions. For the moment I’m still of
the opinion that this
http://nvie.com/posts/a-successful-git-branching-model/ looks good as
it
is…On Tue, Jun 4, 2013 at 12:06 PM, María Arias de Reyna
<delawen@anonymised.com>
wrote:Ok, let’s wait to hear more voices (more comments inline).
On Tue, Jun 4, 2013 at 11:58 AM, heikki <tropicano@anonymised.com> wrote:
On Tue, Jun 4, 2013 at 11:51 AM, María Arias de Reyna
<delawen@…31…>
wrote:On Tue, Jun 4, 2013 at 11:49 AM, María Arias de Reyna
<delawen@anonymised.com>
wrote:On Tue, Jun 4, 2013 at 11:44 AM, heikki <tropicano@anonymised.com>
wrote:
Let me go a bit further with the explanation:If our master is “unstable”, then it will have several features
that
are not intended to go to a stable branch yet.So when do you merge to master, instead of a a stable branch
(those’d
be
like 2.6.x, right?). How to determine whether our master is “stable”
or
not
?As I see it, master itself will never be completely stable, unless we
put all our efforts stabilizing it and not creating new features until
it is stable. But I think it is, more or less, how we work right now.Currently we do not make ‘stable’ branches until a next major
release
is
entering the RC program. E.g., 2.10.x did not exist from at least
the
moment
that 2.8.0 was released. So if you want to develop for the next
stable
release, should you do it on master ? But any commit to master
that’s
not
gone through a QA like the RC process, makes master unstable.In my opinion everything too experimental (very unstable) shouldn’t be
in master. Anything unstable/being tested can be on master.As I understand, right now, when we want to create a new version, we
pick master and stabilize it, right? So the process is not changed on
this part.So master is “the unstable version” ? So if you develop something
on
the
long run, you should commit to master, meaning it will never go to a
stable
version ? That seems unclear too. Of course at some point in time
you
want
it to go to some stable version.Every new 2.y.x will start as master, so anything committed to master
before that is already there.Right now, master is our unstable version, as I understand it. Maybe
because I am thinking on the “unstable” definition of Debian, which is
“almost stable but still needs testing”.Still I think maybe it is more clear to just use the nvie.com mode
as
it
is…We can do it.
… not a superset I mean, of course
On Tue, Jun 4, 2013 at 12:51 PM, heikki <tropicano@anonymised.com> wrote:
I don’t understand your answer…
Even after a release, a release branch remains alive; so for example after we released 2.6.0, the branch 2.6.x remains alive and kicking to this day (if only so we can do emergency fixes to the 2.6 lineage). Same for 2.8.x and 2.10.x.
So now suppose that we changed solution A to solution B in 2.8.0. Then solution B is in 2.8.x and subsequent branches, and in master. Solution A is no longer in master. Therefore master is not a subset of all branches.
On Tue, Jun 4, 2013 at 12:48 PM, María Arias de Reyna <delawen@anonymised.com> wrote:
On Tue, Jun 4, 2013 at 12:47 PM, heikki <tropicano@anonymised.com1…> wrote:
As I read understood the principle, master supposedly is a superset of all
branches. But release branches never die; so in my example, we would have
solution A in branch 2.y.x, and solution B in 2.y+1.x, and they cannot both
be in master.After freezing a release version, it would be merged again to master,
so changes on that version will be available for later versions.If one version overwrites another one, the latest one will prevail (as
in all mergings should be).On Tue, Jun 4, 2013 at 12:44 PM, María Arias de Reyna <delawen@anonymised.com>
wrote:On Tue, Jun 4, 2013 at 12:31 PM, heikki <tropicano@anonymised.com> wrote:
One more remark: “The leading principal is that master branch (trunk in
SVN)
has all the commits and the branches of the specific versions are a
subset
of commits.”Maybe usually true, but it cannot in general be true. For example,
suppose
the we support a version of Java in 2.y.x where there does not exist an
ideal way to do something, so we do it in a less-than-ideal way. In
2.y+1.x
we support a later version of Java, replacing the less than ideal code
with
a better solution. Then in the proposed model, we will be maintaining
both
solutions, one in 2.y.x and one in later branches + master, no?This is actually the case in one place (Jeeves
TransformerFactoryFactory.java, where the 1.5 code is still active by
the
way, but the 1.6 code sits ready in comments).I’m not sure I understand the case.
We did some development in version X. Then we improved the development
in version X+1. As version X+1 was released after version X, then…
where is the problem? Master will contain version X when version X is
released and then some commits later it will contain X+1 version, when
merged.On Tue, Jun 4, 2013 at 12:11 PM, heikki <tropicano@anonymised.com> wrote:
Maybe we should change vocab a little bit. “Stable branch” I think is a
misnomer. The 2.y.x branches are better referred to as “release
branches”,
as any new commits to those will make them unstable too. There’s no
such
thing as a stable branch (except in nvie.com’s model where master is
stable).OK let’s see if other people have opinions. For the moment I’m still of
the opinion that this
http://nvie.com/posts/a-successful-git-branching-model/ looks good as
it
is…On Tue, Jun 4, 2013 at 12:06 PM, María Arias de Reyna
<delawen@anonymised.com>
wrote:Ok, let’s wait to hear more voices (more comments inline).
On Tue, Jun 4, 2013 at 11:58 AM, heikki <tropicano@anonymised.com> wrote:
On Tue, Jun 4, 2013 at 11:51 AM, María Arias de Reyna
<delawen@anonymised.com>
wrote:On Tue, Jun 4, 2013 at 11:49 AM, María Arias de Reyna
<delawen@anonymised.com>
wrote:On Tue, Jun 4, 2013 at 11:44 AM, heikki <tropicano@anonymised.com1…>
wrote:
Let me go a bit further with the explanation:If our master is “unstable”, then it will have several features
that
are not intended to go to a stable branch yet.So when do you merge to master, instead of a a stable branch
(those’d
be
like 2.6.x, right?). How to determine whether our master is “stable”
or
not
?As I see it, master itself will never be completely stable, unless we
put all our efforts stabilizing it and not creating new features until
it is stable. But I think it is, more or less, how we work right now.Currently we do not make ‘stable’ branches until a next major
release
is
entering the RC program. E.g., 2.10.x did not exist from at least
the
moment
that 2.8.0 was released. So if you want to develop for the next
stable
release, should you do it on master ? But any commit to master
that’s
not
gone through a QA like the RC process, makes master unstable.In my opinion everything too experimental (very unstable) shouldn’t be
in master. Anything unstable/being tested can be on master.As I understand, right now, when we want to create a new version, we
pick master and stabilize it, right? So the process is not changed on
this part.So master is “the unstable version” ? So if you develop something
on
the
long run, you should commit to master, meaning it will never go to a
stable
version ? That seems unclear too. Of course at some point in time
you
want
it to go to some stable version.Every new 2.y.x will start as master, so anything committed to master
before that is already there.Right now, master is our unstable version, as I understand it. Maybe
because I am thinking on the “unstable” definition of Debian, which is
“almost stable but still needs testing”.Still I think maybe it is more clear to just use the nvie.com mode
as
it
is…We can do it.
Hmm then again yes the original commit of solution A is still in master… so OK, I guess that’s true then. Sorry about this confusion !
On Tue, Jun 4, 2013 at 12:52 PM, heikki <tropicano@anonymised.com> wrote:
… not a superset I mean, of course
On Tue, Jun 4, 2013 at 12:51 PM, heikki <tropicano@anonymised.com> wrote:
I don’t understand your answer…
Even after a release, a release branch remains alive; so for example after we released 2.6.0, the branch 2.6.x remains alive and kicking to this day (if only so we can do emergency fixes to the 2.6 lineage). Same for 2.8.x and 2.10.x.
So now suppose that we changed solution A to solution B in 2.8.0. Then solution B is in 2.8.x and subsequent branches, and in master. Solution A is no longer in master. Therefore master is not a subset of all branches.
On Tue, Jun 4, 2013 at 12:48 PM, María Arias de Reyna <delawen@anonymised.com> wrote:
On Tue, Jun 4, 2013 at 12:47 PM, heikki <tropicano@anonymised.com1…> wrote:
As I read understood the principle, master supposedly is a superset of all
branches. But release branches never die; so in my example, we would have
solution A in branch 2.y.x, and solution B in 2.y+1.x, and they cannot both
be in master.After freezing a release version, it would be merged again to master,
so changes on that version will be available for later versions.If one version overwrites another one, the latest one will prevail (as
in all mergings should be).On Tue, Jun 4, 2013 at 12:44 PM, María Arias de Reyna <delawen@anonymised.com>
wrote:On Tue, Jun 4, 2013 at 12:31 PM, heikki <tropicano@anonymised.com> wrote:
One more remark: “The leading principal is that master branch (trunk in
SVN)
has all the commits and the branches of the specific versions are a
subset
of commits.”Maybe usually true, but it cannot in general be true. For example,
suppose
the we support a version of Java in 2.y.x where there does not exist an
ideal way to do something, so we do it in a less-than-ideal way. In
2.y+1.x
we support a later version of Java, replacing the less than ideal code
with
a better solution. Then in the proposed model, we will be maintaining
both
solutions, one in 2.y.x and one in later branches + master, no?This is actually the case in one place (Jeeves
TransformerFactoryFactory.java, where the 1.5 code is still active by
the
way, but the 1.6 code sits ready in comments).I’m not sure I understand the case.
We did some development in version X. Then we improved the development
in version X+1. As version X+1 was released after version X, then…
where is the problem? Master will contain version X when version X is
released and then some commits later it will contain X+1 version, when
merged.On Tue, Jun 4, 2013 at 12:11 PM, heikki <tropicano@anonymised.com> wrote:
Maybe we should change vocab a little bit. “Stable branch” I think is a
misnomer. The 2.y.x branches are better referred to as “release
branches”,
as any new commits to those will make them unstable too. There’s no
such
thing as a stable branch (except in nvie.com’s model where master is
stable).OK let’s see if other people have opinions. For the moment I’m still of
the opinion that this
http://nvie.com/posts/a-successful-git-branching-model/ looks good as
it
is…On Tue, Jun 4, 2013 at 12:06 PM, María Arias de Reyna
<delawen@anonymised.com>
wrote:Ok, let’s wait to hear more voices (more comments inline).
On Tue, Jun 4, 2013 at 11:58 AM, heikki <tropicano@anonymised.com> wrote:
On Tue, Jun 4, 2013 at 11:51 AM, María Arias de Reyna
<delawen@anonymised.com>
wrote:On Tue, Jun 4, 2013 at 11:49 AM, María Arias de Reyna
<delawen@anonymised.com>
wrote:On Tue, Jun 4, 2013 at 11:44 AM, heikki <tropicano@anonymised.com1…>
wrote:
Let me go a bit further with the explanation:If our master is “unstable”, then it will have several features
that
are not intended to go to a stable branch yet.So when do you merge to master, instead of a a stable branch
(those’d
be
like 2.6.x, right?). How to determine whether our master is “stable”
or
not
?As I see it, master itself will never be completely stable, unless we
put all our efforts stabilizing it and not creating new features until
it is stable. But I think it is, more or less, how we work right now.Currently we do not make ‘stable’ branches until a next major
release
is
entering the RC program. E.g., 2.10.x did not exist from at least
the
moment
that 2.8.0 was released. So if you want to develop for the next
stable
release, should you do it on master ? But any commit to master
that’s
not
gone through a QA like the RC process, makes master unstable.In my opinion everything too experimental (very unstable) shouldn’t be
in master. Anything unstable/being tested can be on master.As I understand, right now, when we want to create a new version, we
pick master and stabilize it, right? So the process is not changed on
this part.So master is “the unstable version” ? So if you develop something
on
the
long run, you should commit to master, meaning it will never go to a
stable
version ? That seems unclear too. Of course at some point in time
you
want
it to go to some stable version.Every new 2.y.x will start as master, so anything committed to master
before that is already there.Right now, master is our unstable version, as I understand it. Maybe
because I am thinking on the “unstable” definition of Debian, which is
“almost stable but still needs testing”.Still I think maybe it is more clear to just use the nvie.com mode
as
it
is…We can do it.
On Tue, Jun 4, 2013 at 12:51 PM, heikki <tropicano@anonymised.com> wrote:
I don't understand your answer..
Even after a release, a release branch remains alive; so for example after
we released 2.6.0, the branch 2.6.x remains alive and kicking to this day
(if only so we can do emergency fixes to the 2.6 lineage). Same for 2.8.x
and 2.10.x.So now suppose that we changed solution A to solution B in 2.8.0. Then
solution B is in 2.8.x and subsequent branches, and in master. Solution A is
no longer in master. Therefore master is not a subset of all branches.
Well, that is a very special case, I hope we don't have this problem often.
If we have to fix something that is no longer available on later
versions, then of course it is no problem if it is not merged on
master.
It's like http://nvie.com/img/2010/01/hotfix-branches1.png
If it only applies to one old version then it only applies to that version.
Not that special, it happens all the time we change things that are not included in more than one version at the same time. E.g. we change how authentication is handled, it is in branches from the moment of introduction but not in earlier branches. But as I just discovered, I misinterpreted the principle to mean that current master is a superset of all branches, but of course in its commit history, all previous solutions are there, so the principle is stated correctly after all.
On Tue, Jun 4, 2013 at 12:54 PM, María Arias de Reyna <delawen@anonymised.com> wrote:
On Tue, Jun 4, 2013 at 12:51 PM, heikki <tropicano@anonymised.com> wrote:
I don’t understand your answer…
Even after a release, a release branch remains alive; so for example after
we released 2.6.0, the branch 2.6.x remains alive and kicking to this day
(if only so we can do emergency fixes to the 2.6 lineage). Same for 2.8.x
and 2.10.x.So now suppose that we changed solution A to solution B in 2.8.0. Then
solution B is in 2.8.x and subsequent branches, and in master. Solution A is
no longer in master. Therefore master is not a subset of all branches.Well, that is a very special case, I hope we don’t have this problem often.
If we have to fix something that is no longer available on later
versions, then of course it is no problem if it is not merged on
master.It’s like http://nvie.com/img/2010/01/hotfix-branches1.png
If it only applies to one old version then it only applies to that version.
On Tue, Jun 4, 2013 at 12:59 PM, heikki <tropicano@anonymised.com> wrote:
Not that special, it happens all the time we change things that are not
included in more than one version at the same time. E.g. we change how
authentication is handled, it is in branches from the moment of introduction
but not in earlier branches. But as I just discovered, I misinterpreted the
principle to mean that *current* master is a superset of all branches, but
of course in its commit history, all previous solutions are there, so the
principle is stated correctly after all.
Good that we agree on something
I think we are talking alone. No one is really interested on this after all....
On Tue, Jun 4, 2013 at 12:54 PM, María Arias de Reyna <delawen@anonymised.com>
wrote:On Tue, Jun 4, 2013 at 12:51 PM, heikki <tropicano@anonymised.com> wrote:
> I don't understand your answer..
>
> Even after a release, a release branch remains alive; so for example
> after
> we released 2.6.0, the branch 2.6.x remains alive and kicking to this
> day
> (if only so we can do emergency fixes to the 2.6 lineage). Same for
> 2.8.x
> and 2.10.x.
>
> So now suppose that we changed solution A to solution B in 2.8.0. Then
> solution B is in 2.8.x and subsequent branches, and in master. Solution
> A is
> no longer in master. Therefore master is not a subset of all branches.
>
>Well, that is a very special case, I hope we don't have this problem
often.If we have to fix something that is no longer available on later
versions, then of course it is no problem if it is not merged on
master.It's like http://nvie.com/img/2010/01/hotfix-branches1.png
If it only applies to one old version then it only applies to that
version.
I am actually interested in this kind of stuff 
On Tue, Jun 4, 2013 at 1:01 PM, María Arias de Reyna <delawen@anonymised.com> wrote:
On Tue, Jun 4, 2013 at 12:59 PM, heikki <tropicano@anonymised.com> wrote:
Not that special, it happens all the time we change things that are not
included in more than one version at the same time. E.g. we change how
authentication is handled, it is in branches from the moment of introduction
but not in earlier branches. But as I just discovered, I misinterpreted the
principle to mean that current master is a superset of all branches, but
of course in its commit history, all previous solutions are there, so the
principle is stated correctly after all.Good that we agree on something
I think we are talking alone. No one is really interested on this after all…
On Tue, Jun 4, 2013 at 12:54 PM, María Arias de Reyna <delawen@anonymised.com>
wrote:On Tue, Jun 4, 2013 at 12:51 PM, heikki <tropicano@anonymised.com> wrote:
I don’t understand your answer…
Even after a release, a release branch remains alive; so for example
after
we released 2.6.0, the branch 2.6.x remains alive and kicking to this
day
(if only so we can do emergency fixes to the 2.6 lineage). Same for
2.8.x
and 2.10.x.So now suppose that we changed solution A to solution B in 2.8.0. Then
solution B is in 2.8.x and subsequent branches, and in master. Solution
A is
no longer in master. Therefore master is not a subset of all branches.Well, that is a very special case, I hope we don’t have this problem
often.If we have to fix something that is no longer available on later
versions, then of course it is no problem if it is not merged on
master.It’s like http://nvie.com/img/2010/01/hotfix-branches1.png
If it only applies to one old version then it only applies to that
version.