Discussion:
[DISCUSS] No more release branches for 1.x, release from branch-1 directly
Andrew Purtell
2018-12-07 19:35:58 UTC
Permalink
Please be advised I plan to RM the next minor release from branch-1, 1.5.0,
in January of 2019. Once this is done we can continue making maintenance
releases from branch-1.4 as needed but expect that not to be necessary
after a couple of months (or perhaps even immediately).

I see no need to make a branch-1.5. As community resources continue to
shift away from branch-1 we need to conserve available attention. I don't
see why we cannot release directly from branch-1. Certainly in the
beginning any branch-1.5 would be lock step with branch-1. No distinction
in branch curation means no need for a new branch, at least initially.
Also, should a commit land in branch-1 that requires a new minor per our
compatibility guidelines then I don't see why the next release from
branch-1 cannot a new minor (1.6.0, etc.) right there and then. We have
expressed intent to make more frequent minor releases anyhow.

Related, I started a DISCUSS thread about EOL of branch-1.3.

In my opinion the optimal future for branch-1, until all attention moves
away from it, is continuing releases directly from branch-1 and perhaps
branch-1.2 (depends on Busbey's plans for it).

If you would prefer we continue to make new branches for minor code lines,
I can do that for 1.5, no problem, but perhaps you will agree it is no
longer necessary.
--
Best regards,
Andrew

Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
- A23, Crosstalk
Sean Busbey
2018-12-07 20:05:09 UTC
Permalink
yes please this would be great!

I have a DISCUSS thread I've been drafting about doing the same thing
for branch-2 releases. I think in general we need to get back in the
habit of only making maintenance releases when someone steps forward
with a specific need.

I plan to keep making branch-1.2 releases until April 2019.
Post by Andrew Purtell
Please be advised I plan to RM the next minor release from branch-1, 1.5.0,
in January of 2019. Once this is done we can continue making maintenance
releases from branch-1.4 as needed but expect that not to be necessary
after a couple of months (or perhaps even immediately).
I see no need to make a branch-1.5. As community resources continue to
shift away from branch-1 we need to conserve available attention. I don't
see why we cannot release directly from branch-1. Certainly in the
beginning any branch-1.5 would be lock step with branch-1. No distinction
in branch curation means no need for a new branch, at least initially.
Also, should a commit land in branch-1 that requires a new minor per our
compatibility guidelines then I don't see why the next release from
branch-1 cannot a new minor (1.6.0, etc.) right there and then. We have
expressed intent to make more frequent minor releases anyhow.
Related, I started a DISCUSS thread about EOL of branch-1.3.
In my opinion the optimal future for branch-1, until all attention moves
away from it, is continuing releases directly from branch-1 and perhaps
branch-1.2 (depends on Busbey's plans for it).
If you would prefer we continue to make new branches for minor code lines,
I can do that for 1.5, no problem, but perhaps you will agree it is no
longer necessary.
--
Best regards,
Andrew
Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
- A23, Crosstalk
Stack
2018-12-07 20:14:50 UTC
Permalink
Post by Andrew Purtell
Please be advised I plan to RM the next minor release from branch-1, 1.5.0,
in January of 2019. Once this is done we can continue making maintenance
releases from branch-1.4 as needed but expect that not to be necessary
after a couple of months (or perhaps even immediately).
I see no need to make a branch-1.5. As community resources continue to
shift away from branch-1 we need to conserve available attention. I don't
see why we cannot release directly from branch-1. Certainly in the
beginning any branch-1.5 would be lock step with branch-1. No distinction
in branch curation means no need for a new branch, at least initially.
Also, should a commit land in branch-1 that requires a new minor per our
compatibility guidelines then I don't see why the next release from
branch-1 cannot a new minor (1.6.0, etc.) right there and then. We have
expressed intent to make more frequent minor releases anyhow.
Related, I started a DISCUSS thread about EOL of branch-1.3.
In my opinion the optimal future for branch-1, until all attention moves
away from it, is continuing releases directly from branch-1 and perhaps
branch-1.2 (depends on Busbey's plans for it).
If you would prefer we continue to make new branches for minor code lines,
I can do that for 1.5, no problem, but perhaps you will agree it is no
longer necessary.
Agree.
I also like the idea of doing same thing for branch-2.

S
Post by Andrew Purtell
--
Best regards,
Andrew
Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
- A23, Crosstalk
张铎(Duo Zhang)
2018-12-08 01:25:27 UTC
Permalink
So the idea is that, if we have a newer major release line, we can release
the previous major releases directly from the 'developing' branch?

I think for branch-1 it is fine, as we are not likely to backport any big
new feature to 1.x any more. And does this mean that 1.5 is the last minor
release line for 1.x?
Post by Andrew Purtell
Post by Andrew Purtell
Please be advised I plan to RM the next minor release from branch-1,
1.5.0,
Post by Andrew Purtell
in January of 2019. Once this is done we can continue making maintenance
releases from branch-1.4 as needed but expect that not to be necessary
after a couple of months (or perhaps even immediately).
I see no need to make a branch-1.5. As community resources continue to
shift away from branch-1 we need to conserve available attention. I don't
see why we cannot release directly from branch-1. Certainly in the
beginning any branch-1.5 would be lock step with branch-1. No distinction
in branch curation means no need for a new branch, at least initially.
Also, should a commit land in branch-1 that requires a new minor per our
compatibility guidelines then I don't see why the next release from
branch-1 cannot a new minor (1.6.0, etc.) right there and then. We have
expressed intent to make more frequent minor releases anyhow.
Related, I started a DISCUSS thread about EOL of branch-1.3.
In my opinion the optimal future for branch-1, until all attention moves
away from it, is continuing releases directly from branch-1 and perhaps
branch-1.2 (depends on Busbey's plans for it).
If you would prefer we continue to make new branches for minor code
lines,
Post by Andrew Purtell
I can do that for 1.5, no problem, but perhaps you will agree it is no
longer necessary.
Agree.
I also like the idea of doing same thing for branch-2.
S
Post by Andrew Purtell
--
Best regards,
Andrew
Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
- A23, Crosstalk
Andrew Purtell
2018-12-08 01:35:38 UTC
Permalink
Yeah, for branch-1 it is no longer a development branch. Every change is
going to be maintenance related. No, I don't expect 1.5 to be the last
minor release line for 1.x. Maybe? Maybe not. In theory we could treat
branch-2 the same. Master is the only development branch. That is not my
proposal, though. I'm only concerned with RM activities related to
branch-1.
Post by 张铎(Duo Zhang)
So the idea is that, if we have a newer major release line, we can release
the previous major releases directly from the 'developing' branch?
I think for branch-1 it is fine, as we are not likely to backport any big
new feature to 1.x any more. And does this mean that 1.5 is the last minor
release line for 1.x?
Post by Andrew Purtell
Post by Andrew Purtell
Please be advised I plan to RM the next minor release from branch-1,
1.5.0,
Post by Andrew Purtell
in January of 2019. Once this is done we can continue making
maintenance
Post by Andrew Purtell
Post by Andrew Purtell
releases from branch-1.4 as needed but expect that not to be necessary
after a couple of months (or perhaps even immediately).
I see no need to make a branch-1.5. As community resources continue to
shift away from branch-1 we need to conserve available attention. I
don't
Post by Andrew Purtell
Post by Andrew Purtell
see why we cannot release directly from branch-1. Certainly in the
beginning any branch-1.5 would be lock step with branch-1. No
distinction
Post by Andrew Purtell
Post by Andrew Purtell
in branch curation means no need for a new branch, at least initially.
Also, should a commit land in branch-1 that requires a new minor per
our
Post by Andrew Purtell
Post by Andrew Purtell
compatibility guidelines then I don't see why the next release from
branch-1 cannot a new minor (1.6.0, etc.) right there and then. We have
expressed intent to make more frequent minor releases anyhow.
Related, I started a DISCUSS thread about EOL of branch-1.3.
In my opinion the optimal future for branch-1, until all attention
moves
Post by Andrew Purtell
Post by Andrew Purtell
away from it, is continuing releases directly from branch-1 and perhaps
branch-1.2 (depends on Busbey's plans for it).
If you would prefer we continue to make new branches for minor code
lines,
Post by Andrew Purtell
I can do that for 1.5, no problem, but perhaps you will agree it is no
longer necessary.
Agree.
I also like the idea of doing same thing for branch-2.
S
Post by Andrew Purtell
--
Best regards,
Andrew
Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
- A23, Crosstalk
--
Best regards,
Andrew

Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
- A23, Crosstalk
张铎(Duo Zhang)
2018-12-08 01:47:34 UTC
Permalink
If 1.5 is not the last minor release line, then how do we release 1.6? Make
a branch-1.5 and then start to release 1.6 from branch-1?
Post by Andrew Purtell
Yeah, for branch-1 it is no longer a development branch. Every change is
going to be maintenance related. No, I don't expect 1.5 to be the last
minor release line for 1.x. Maybe? Maybe not. In theory we could treat
branch-2 the same. Master is the only development branch. That is not my
proposal, though. I'm only concerned with RM activities related to
branch-1.
Post by 张铎(Duo Zhang)
So the idea is that, if we have a newer major release line, we can
release
Post by 张铎(Duo Zhang)
the previous major releases directly from the 'developing' branch?
I think for branch-1 it is fine, as we are not likely to backport any big
new feature to 1.x any more. And does this mean that 1.5 is the last
minor
Post by 张铎(Duo Zhang)
release line for 1.x?
Post by Andrew Purtell
Post by Andrew Purtell
Please be advised I plan to RM the next minor release from branch-1,
1.5.0,
Post by Andrew Purtell
in January of 2019. Once this is done we can continue making
maintenance
Post by Andrew Purtell
Post by Andrew Purtell
releases from branch-1.4 as needed but expect that not to be
necessary
Post by 张铎(Duo Zhang)
Post by Andrew Purtell
Post by Andrew Purtell
after a couple of months (or perhaps even immediately).
I see no need to make a branch-1.5. As community resources continue
to
Post by 张铎(Duo Zhang)
Post by Andrew Purtell
Post by Andrew Purtell
shift away from branch-1 we need to conserve available attention. I
don't
Post by Andrew Purtell
Post by Andrew Purtell
see why we cannot release directly from branch-1. Certainly in the
beginning any branch-1.5 would be lock step with branch-1. No
distinction
Post by Andrew Purtell
Post by Andrew Purtell
in branch curation means no need for a new branch, at least
initially.
Post by 张铎(Duo Zhang)
Post by Andrew Purtell
Post by Andrew Purtell
Also, should a commit land in branch-1 that requires a new minor per
our
Post by Andrew Purtell
Post by Andrew Purtell
compatibility guidelines then I don't see why the next release from
branch-1 cannot a new minor (1.6.0, etc.) right there and then. We
have
Post by 张铎(Duo Zhang)
Post by Andrew Purtell
Post by Andrew Purtell
expressed intent to make more frequent minor releases anyhow.
Related, I started a DISCUSS thread about EOL of branch-1.3.
In my opinion the optimal future for branch-1, until all attention
moves
Post by Andrew Purtell
Post by Andrew Purtell
away from it, is continuing releases directly from branch-1 and
perhaps
Post by 张铎(Duo Zhang)
Post by Andrew Purtell
Post by Andrew Purtell
branch-1.2 (depends on Busbey's plans for it).
If you would prefer we continue to make new branches for minor code
lines,
Post by Andrew Purtell
I can do that for 1.5, no problem, but perhaps you will agree it is
no
Post by 张铎(Duo Zhang)
Post by Andrew Purtell
Post by Andrew Purtell
longer necessary.
Agree.
I also like the idea of doing same thing for branch-2.
S
Post by Andrew Purtell
--
Best regards,
Andrew
Words like orphans lost among the crosstalk, meaning torn from
truth's
Post by 张铎(Duo Zhang)
Post by Andrew Purtell
Post by Andrew Purtell
decrepit hands
- A23, Crosstalk
--
Best regards,
Andrew
Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
- A23, Crosstalk
Andrew Purtell
2018-12-08 01:59:16 UTC
Permalink
We could do that. Or we could simply renumber branch-1 to 1.6.x at that
time, e.g. 1.5.whatever-SNAPSHOT -> 1.6.0-SNAPSHOT. Every release has a tag
in rel/. It is possible at any time to check out from a release tag and
make a branch for an additional patch release for an old minor line. If we
need to do it, we can at that time, otherwise why proliferate branches and
make more work for committers? I think for branch-1 after moving from
1.5.whatever to 1.6.0 any additional 1.5.x releases would be unlikely, and
going forward for 1.6, and so on. This same policy could work for branch-2.
We shouldn't be afraid to make new minors. Prior to 1.0.0 every release was
a minor release and patch releases were rare. I think we want to get back
to something more like that.

It also makes sense to have a long term stable branch. That is currently
branch-1.2. If in the future we want it to be 1.5, then at that time it
makes sense to have a separate branch-1.5 for the LTS.
Post by 张铎(Duo Zhang)
If 1.5 is not the last minor release line, then how do we release 1.6? Make
a branch-1.5 and then start to release 1.6 from branch-1?
Post by Andrew Purtell
Yeah, for branch-1 it is no longer a development branch. Every change is
going to be maintenance related. No, I don't expect 1.5 to be the last
minor release line for 1.x. Maybe? Maybe not. In theory we could treat
branch-2 the same. Master is the only development branch. That is not my
proposal, though. I'm only concerned with RM activities related to
branch-1.
Post by 张铎(Duo Zhang)
So the idea is that, if we have a newer major release line, we can
release
Post by 张铎(Duo Zhang)
the previous major releases directly from the 'developing' branch?
I think for branch-1 it is fine, as we are not likely to backport any
big
Post by Andrew Purtell
Post by 张铎(Duo Zhang)
new feature to 1.x any more. And does this mean that 1.5 is the last
minor
Post by 张铎(Duo Zhang)
release line for 1.x?
Post by Andrew Purtell
Post by Andrew Purtell
Please be advised I plan to RM the next minor release from
branch-1,
Post by Andrew Purtell
Post by 张铎(Duo Zhang)
Post by Andrew Purtell
1.5.0,
Post by Andrew Purtell
in January of 2019. Once this is done we can continue making
maintenance
Post by Andrew Purtell
Post by Andrew Purtell
releases from branch-1.4 as needed but expect that not to be
necessary
Post by 张铎(Duo Zhang)
Post by Andrew Purtell
Post by Andrew Purtell
after a couple of months (or perhaps even immediately).
I see no need to make a branch-1.5. As community resources continue
to
Post by 张铎(Duo Zhang)
Post by Andrew Purtell
Post by Andrew Purtell
shift away from branch-1 we need to conserve available attention. I
don't
Post by Andrew Purtell
Post by Andrew Purtell
see why we cannot release directly from branch-1. Certainly in the
beginning any branch-1.5 would be lock step with branch-1. No
distinction
Post by Andrew Purtell
Post by Andrew Purtell
in branch curation means no need for a new branch, at least
initially.
Post by 张铎(Duo Zhang)
Post by Andrew Purtell
Post by Andrew Purtell
Also, should a commit land in branch-1 that requires a new minor
per
Post by Andrew Purtell
Post by 张铎(Duo Zhang)
our
Post by Andrew Purtell
Post by Andrew Purtell
compatibility guidelines then I don't see why the next release from
branch-1 cannot a new minor (1.6.0, etc.) right there and then. We
have
Post by 张铎(Duo Zhang)
Post by Andrew Purtell
Post by Andrew Purtell
expressed intent to make more frequent minor releases anyhow.
Related, I started a DISCUSS thread about EOL of branch-1.3.
In my opinion the optimal future for branch-1, until all attention
moves
Post by Andrew Purtell
Post by Andrew Purtell
away from it, is continuing releases directly from branch-1 and
perhaps
Post by 张铎(Duo Zhang)
Post by Andrew Purtell
Post by Andrew Purtell
branch-1.2 (depends on Busbey's plans for it).
If you would prefer we continue to make new branches for minor code
lines,
Post by Andrew Purtell
I can do that for 1.5, no problem, but perhaps you will agree it is
no
Post by 张铎(Duo Zhang)
Post by Andrew Purtell
Post by Andrew Purtell
longer necessary.
Agree.
I also like the idea of doing same thing for branch-2.
S
Post by Andrew Purtell
--
Best regards,
Andrew
Words like orphans lost among the crosstalk, meaning torn from
truth's
Post by 张铎(Duo Zhang)
Post by Andrew Purtell
Post by Andrew Purtell
decrepit hands
- A23, Crosstalk
--
Best regards,
Andrew
Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
- A23, Crosstalk
--
Best regards,
Andrew

Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
- A23, Crosstalk
Stack
2018-12-08 23:34:38 UTC
Permalink
Post by Andrew Purtell
We could do that. Or we could simply renumber branch-1 to 1.6.x at that
time, e.g. 1.5.whatever-SNAPSHOT -> 1.6.0-SNAPSHOT. Every release has a tag
in rel/. It is possible at any time to check out from a release tag and
make a branch for an additional patch release for an old minor line. If we
need to do it, we can at that time, otherwise why proliferate branches and
make more work for committers? I think for branch-1 after moving from
1.5.whatever to 1.6.0 any additional 1.5.x releases would be unlikely, and
going forward for 1.6, and so on. This same policy could work for branch-2.
We shouldn't be afraid to make new minors. Prior to 1.0.0 every release was
a minor release and patch releases were rare. I think we want to get back
to something more like that.
It also makes sense to have a long term stable branch. That is currently
branch-1.2. If in the future we want it to be 1.5, then at that time it
makes sense to have a separate branch-1.5 for the LTS.
Let's try it.

Should be easy to do on branch-1 what with a single 'owner'.

branch-2 would prove a more interesting experiment. Let branch-2 be where
we cut 2.2.0 and 2.2.1, etc., from? (We need an RM for 2.2....)

S
Post by Andrew Purtell
Post by 张铎(Duo Zhang)
If 1.5 is not the last minor release line, then how do we release 1.6?
Make
Post by 张铎(Duo Zhang)
a branch-1.5 and then start to release 1.6 from branch-1?
Post by Andrew Purtell
Yeah, for branch-1 it is no longer a development branch. Every change
is
Post by 张铎(Duo Zhang)
Post by Andrew Purtell
going to be maintenance related. No, I don't expect 1.5 to be the last
minor release line for 1.x. Maybe? Maybe not. In theory we could treat
branch-2 the same. Master is the only development branch. That is not
my
Post by 张铎(Duo Zhang)
Post by Andrew Purtell
proposal, though. I'm only concerned with RM activities related to
branch-1.
Post by 张铎(Duo Zhang)
So the idea is that, if we have a newer major release line, we can
release
Post by 张铎(Duo Zhang)
the previous major releases directly from the 'developing' branch?
I think for branch-1 it is fine, as we are not likely to backport any
big
Post by Andrew Purtell
Post by 张铎(Duo Zhang)
new feature to 1.x any more. And does this mean that 1.5 is the last
minor
Post by 张铎(Duo Zhang)
release line for 1.x?
On Fri, Dec 7, 2018 at 11:36 AM Andrew Purtell <
Post by Andrew Purtell
Please be advised I plan to RM the next minor release from
branch-1,
Post by Andrew Purtell
Post by 张铎(Duo Zhang)
1.5.0,
Post by Andrew Purtell
in January of 2019. Once this is done we can continue making
maintenance
Post by Andrew Purtell
releases from branch-1.4 as needed but expect that not to be
necessary
Post by 张铎(Duo Zhang)
Post by Andrew Purtell
after a couple of months (or perhaps even immediately).
I see no need to make a branch-1.5. As community resources
continue
Post by 张铎(Duo Zhang)
Post by Andrew Purtell
to
Post by 张铎(Duo Zhang)
Post by Andrew Purtell
shift away from branch-1 we need to conserve available
attention. I
Post by 张铎(Duo Zhang)
Post by Andrew Purtell
Post by 张铎(Duo Zhang)
don't
Post by Andrew Purtell
see why we cannot release directly from branch-1. Certainly in
the
Post by 张铎(Duo Zhang)
Post by Andrew Purtell
Post by 张铎(Duo Zhang)
Post by Andrew Purtell
beginning any branch-1.5 would be lock step with branch-1. No
distinction
Post by Andrew Purtell
in branch curation means no need for a new branch, at least
initially.
Post by 张铎(Duo Zhang)
Post by Andrew Purtell
Also, should a commit land in branch-1 that requires a new minor
per
Post by Andrew Purtell
Post by 张铎(Duo Zhang)
our
Post by Andrew Purtell
compatibility guidelines then I don't see why the next release
from
Post by 张铎(Duo Zhang)
Post by Andrew Purtell
Post by 张铎(Duo Zhang)
Post by Andrew Purtell
branch-1 cannot a new minor (1.6.0, etc.) right there and then.
We
Post by 张铎(Duo Zhang)
Post by Andrew Purtell
have
Post by 张铎(Duo Zhang)
Post by Andrew Purtell
expressed intent to make more frequent minor releases anyhow.
Related, I started a DISCUSS thread about EOL of branch-1.3.
In my opinion the optimal future for branch-1, until all
attention
Post by 张铎(Duo Zhang)
Post by Andrew Purtell
Post by 张铎(Duo Zhang)
moves
Post by Andrew Purtell
away from it, is continuing releases directly from branch-1 and
perhaps
Post by 张铎(Duo Zhang)
Post by Andrew Purtell
branch-1.2 (depends on Busbey's plans for it).
If you would prefer we continue to make new branches for minor
code
Post by 张铎(Duo Zhang)
Post by Andrew Purtell
Post by 张铎(Duo Zhang)
lines,
Post by Andrew Purtell
I can do that for 1.5, no problem, but perhaps you will agree it
is
Post by 张铎(Duo Zhang)
Post by Andrew Purtell
no
Post by 张铎(Duo Zhang)
Post by Andrew Purtell
longer necessary.
Agree.
I also like the idea of doing same thing for branch-2.
S
Post by Andrew Purtell
--
Best regards,
Andrew
Words like orphans lost among the crosstalk, meaning torn from
truth's
Post by 张铎(Duo Zhang)
Post by Andrew Purtell
decrepit hands
- A23, Crosstalk
--
Best regards,
Andrew
Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
- A23, Crosstalk
--
Best regards,
Andrew
Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
- A23, Crosstalk
Allan Yang
2018-12-09 04:02:27 UTC
Permalink
I think Andrew's way makes sense for branch-1, we can release 1.6,1.7 and
so on directly on branch-1. Since in branch-1, we will only have bug fixes.
If we want to apply this policy to branch-2, we'd be careful when new
functions check in, because all feature releases will include this function
if we only have a branch-2. But good news is that we only need to commit
our code to one branch, for now, sometimes I need to commit to four
branches(branch-2.0, branch-2.1, branch-2 and master). And for users, they
don't have to make difficult chose about which release line they need to
use. And they don't have to consider about compatibility when upgrading a
minor version. We make sure all the Incompatible changes are only commit to
master branch(for releasing 3.x).

Best Regards
Allan Yang
Post by Stack
Post by Andrew Purtell
We could do that. Or we could simply renumber branch-1 to 1.6.x at that
time, e.g. 1.5.whatever-SNAPSHOT -> 1.6.0-SNAPSHOT. Every release has a
tag
Post by Andrew Purtell
in rel/. It is possible at any time to check out from a release tag and
make a branch for an additional patch release for an old minor line. If
we
Post by Andrew Purtell
need to do it, we can at that time, otherwise why proliferate branches
and
Post by Andrew Purtell
make more work for committers? I think for branch-1 after moving from
1.5.whatever to 1.6.0 any additional 1.5.x releases would be unlikely,
and
Post by Andrew Purtell
going forward for 1.6, and so on. This same policy could work for
branch-2.
Post by Andrew Purtell
We shouldn't be afraid to make new minors. Prior to 1.0.0 every release
was
Post by Andrew Purtell
a minor release and patch releases were rare. I think we want to get back
to something more like that.
It also makes sense to have a long term stable branch. That is currently
branch-1.2. If in the future we want it to be 1.5, then at that time it
makes sense to have a separate branch-1.5 for the LTS.
Let's try it.
Should be easy to do on branch-1 what with a single 'owner'.
branch-2 would prove a more interesting experiment. Let branch-2 be where
we cut 2.2.0 and 2.2.1, etc., from? (We need an RM for 2.2....)
S
Post by Andrew Purtell
Post by 张铎(Duo Zhang)
If 1.5 is not the last minor release line, then how do we release 1.6?
Make
Post by 张铎(Duo Zhang)
a branch-1.5 and then start to release 1.6 from branch-1?
Post by Andrew Purtell
Yeah, for branch-1 it is no longer a development branch. Every change
is
Post by 张铎(Duo Zhang)
Post by Andrew Purtell
going to be maintenance related. No, I don't expect 1.5 to be the
last
Post by Andrew Purtell
Post by 张铎(Duo Zhang)
Post by Andrew Purtell
minor release line for 1.x. Maybe? Maybe not. In theory we could
treat
Post by Andrew Purtell
Post by 张铎(Duo Zhang)
Post by Andrew Purtell
branch-2 the same. Master is the only development branch. That is not
my
Post by 张铎(Duo Zhang)
Post by Andrew Purtell
proposal, though. I'm only concerned with RM activities related to
branch-1.
Post by 张铎(Duo Zhang)
So the idea is that, if we have a newer major release line, we can
release
Post by 张铎(Duo Zhang)
the previous major releases directly from the 'developing' branch?
I think for branch-1 it is fine, as we are not likely to backport
any
Post by Andrew Purtell
Post by 张铎(Duo Zhang)
big
Post by Andrew Purtell
Post by 张铎(Duo Zhang)
new feature to 1.x any more. And does this mean that 1.5 is the
last
Post by Andrew Purtell
Post by 张铎(Duo Zhang)
Post by Andrew Purtell
minor
Post by 张铎(Duo Zhang)
release line for 1.x?
On Fri, Dec 7, 2018 at 11:36 AM Andrew Purtell <
Post by Andrew Purtell
Please be advised I plan to RM the next minor release from
branch-1,
Post by Andrew Purtell
Post by 张铎(Duo Zhang)
1.5.0,
Post by Andrew Purtell
in January of 2019. Once this is done we can continue making
maintenance
Post by Andrew Purtell
releases from branch-1.4 as needed but expect that not to be
necessary
Post by 张铎(Duo Zhang)
Post by Andrew Purtell
after a couple of months (or perhaps even immediately).
I see no need to make a branch-1.5. As community resources
continue
Post by 张铎(Duo Zhang)
Post by Andrew Purtell
to
Post by 张铎(Duo Zhang)
Post by Andrew Purtell
shift away from branch-1 we need to conserve available
attention. I
Post by 张铎(Duo Zhang)
Post by Andrew Purtell
Post by 张铎(Duo Zhang)
don't
Post by Andrew Purtell
see why we cannot release directly from branch-1. Certainly in
the
Post by 张铎(Duo Zhang)
Post by Andrew Purtell
Post by 张铎(Duo Zhang)
Post by Andrew Purtell
beginning any branch-1.5 would be lock step with branch-1. No
distinction
Post by Andrew Purtell
in branch curation means no need for a new branch, at least
initially.
Post by 张铎(Duo Zhang)
Post by Andrew Purtell
Also, should a commit land in branch-1 that requires a new
minor
Post by Andrew Purtell
Post by 张铎(Duo Zhang)
per
Post by Andrew Purtell
Post by 张铎(Duo Zhang)
our
Post by Andrew Purtell
compatibility guidelines then I don't see why the next release
from
Post by 张铎(Duo Zhang)
Post by Andrew Purtell
Post by 张铎(Duo Zhang)
Post by Andrew Purtell
branch-1 cannot a new minor (1.6.0, etc.) right there and then.
We
Post by 张铎(Duo Zhang)
Post by Andrew Purtell
have
Post by 张铎(Duo Zhang)
Post by Andrew Purtell
expressed intent to make more frequent minor releases anyhow.
Related, I started a DISCUSS thread about EOL of branch-1.3.
In my opinion the optimal future for branch-1, until all
attention
Post by 张铎(Duo Zhang)
Post by Andrew Purtell
Post by 张铎(Duo Zhang)
moves
Post by Andrew Purtell
away from it, is continuing releases directly from branch-1 and
perhaps
Post by 张铎(Duo Zhang)
Post by Andrew Purtell
branch-1.2 (depends on Busbey's plans for it).
If you would prefer we continue to make new branches for minor
code
Post by 张铎(Duo Zhang)
Post by Andrew Purtell
Post by 张铎(Duo Zhang)
lines,
Post by Andrew Purtell
I can do that for 1.5, no problem, but perhaps you will agree
it
Post by Andrew Purtell
is
Post by 张铎(Duo Zhang)
Post by Andrew Purtell
no
Post by 张铎(Duo Zhang)
Post by Andrew Purtell
longer necessary.
Agree.
I also like the idea of doing same thing for branch-2.
S
Post by Andrew Purtell
--
Best regards,
Andrew
Words like orphans lost among the crosstalk, meaning torn from
truth's
Post by 张铎(Duo Zhang)
Post by Andrew Purtell
decrepit hands
- A23, Crosstalk
--
Best regards,
Andrew
Words like orphans lost among the crosstalk, meaning torn from
truth's
Post by Andrew Purtell
Post by 张铎(Duo Zhang)
Post by Andrew Purtell
decrepit hands
- A23, Crosstalk
--
Best regards,
Andrew
Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
- A23, Crosstalk
Loading...