You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Noah Slater <ns...@apache.org> on 2013/05/07 20:34:14 UTC
[DISCUSS] Release clean-up (delete ALL the branches!)
Devs,
We're switching over to time-based releases.
I took a moment to review our existing release branches today, and I have
prepared a list of recommendations for you. Please review these and give me
feedback.
By "drop support" I mean "make official" and while this is ostensibly the
case for a few of these, what I _really_ mean is "delete the branch". I see
no reason to keep this stuff around. It would make my life a lot easier if
we could clean this stuff up.
I'm not a Git expert, so I am relying on someone to sanity check this.
Remember: if we ever want to patch up a security issue in an unsupported
release, we will be issuing a patch. So I am assuming what we'll want to do
is patch against the last tag for that release line. No need for the branch
at all as far as I can tell.
If nobody objects in 72 hours, I will assume lazy consensus and proceed.
## 0.10.x line and before
Really old stuff.
Recommendation:
* Drop support of these release lines
* Delete the branches
## 0.11.x line
First release: March 2010 (three years old)
Unreleased changes:
* Fix for frequently edited documents in multi-master deployments being
duplicated in _changes and _all_docs.
Recommendation:
* Do not release these changes
* Drop support of this release line
* Delete the branch
## 1.0.x line
First release: July 2010 (three years old)
No unreleased changes.
Recommendation:
* Drop support of this release line
* Delete the branch
## 1.1.x line
First release: July 2011 (two years old)
No unreleased changes.
Recommendation:
* Drop support of this release line
* Delete the branch
## 1.2.x line
First release: April 2012 (one year old)
No unreleased changes.
1.3.x line is backwards compatible with 1.2.x.
Recommendation:
* Drop support of this release line
* Delete the branch
## 1.3.x line
First release: April 2013 (one month old)
Unreleased changes:
* Whatever bugfixes are on master or in branches right now.
Recommendation:
* Release 1.3.1 this month.
Thanks,
--
NS
Re: [DISCUSS] Release clean-up (delete ALL the branches!)
Posted by Garren Smith <ga...@apache.org>.
+1
On 07 May 2013, at 11:15 PM, Noah Slater <ns...@apache.org> wrote:
> (Note: the work was valuable any how, because master now has an accurate
> record of history.)
>
>
> On 7 May 2013 20:01, Dave Cottlehuber <dc...@jsonified.com> wrote:
>
>> On 7 May 2013 20:34, Noah Slater <ns...@apache.org> wrote:
>>
>>> Devs,
>>>
>>> We're switching over to time-based releases.
>>>
>>> I took a moment to review our existing release branches today, and I have
>>> prepared a list of recommendations for you. Please review these and give
>> me
>>> feedback.
>>>
>>> By "drop support" I mean "make official" and while this is ostensibly the
>>> case for a few of these, what I _really_ mean is "delete the branch". I
>> see
>>> no reason to keep this stuff around. It would make my life a lot easier
>> if
>>> we could clean this stuff up.
>>>
>>> I'm not a Git expert, so I am relying on someone to sanity check this.
>>> Remember: if we ever want to patch up a security issue in an unsupported
>>> release, we will be issuing a patch. So I am assuming what we'll want to
>> do
>>> is patch against the last tag for that release line. No need for the
>> branch
>>> at all as far as I can tell.
>>>
>>> If nobody objects in 72 hours, I will assume lazy consensus and proceed.
>>>
>>> ## 0.10.x line and before
>>>
>>> Really old stuff.
>>>
>>> Recommendation:
>>>
>>> * Drop support of these release lines
>>> * Delete the branches
>>>
>>> ## 0.11.x line
>>>
>>> First release: March 2010 (three years old)
>>>
>>> Unreleased changes:
>>>
>>> * Fix for frequently edited documents in multi-master deployments being
>>> duplicated in _changes and _all_docs.
>>>
>>> Recommendation:
>>>
>>> * Do not release these changes
>>> * Drop support of this release line
>>> * Delete the branch
>>>
>>> ## 1.0.x line
>>>
>>> First release: July 2010 (three years old)
>>>
>>> No unreleased changes.
>>>
>>> Recommendation:
>>>
>>> * Drop support of this release line
>>> * Delete the branch
>>>
>>> ## 1.1.x line
>>>
>>> First release: July 2011 (two years old)
>>>
>>> No unreleased changes.
>>>
>>> Recommendation:
>>>
>>> * Drop support of this release line
>>> * Delete the branch
>>>
>>> ## 1.2.x line
>>>
>>> First release: April 2012 (one year old)
>>>
>>> No unreleased changes.
>>>
>>> 1.3.x line is backwards compatible with 1.2.x.
>>>
>>> Recommendation:
>>>
>>> * Drop support of this release line
>>> * Delete the branch
>>>
>>> ## 1.3.x line
>>>
>>> First release: April 2013 (one month old)
>>>
>>> Unreleased changes:
>>>
>>> * Whatever bugfixes are on master or in branches right now.
>>>
>>> Recommendation:
>>>
>>> * Release 1.3.1 this month.
>>>
>>> Thanks,
>>>
>>> --
>>> NS
>>>
>>
>> +1.
>>
>> You might consider tagging the last commit in each branch before you dump
>> it. e.g. you have all those nice changes in NEWS/CHANGES etc that you
>> slaved away on, in the above proposal they'd be lost.
>>
>
>
>
> --
> NS
Re: [DISCUSS] Release clean-up (delete ALL the branches!)
Posted by Noah Slater <ns...@apache.org>.
(Note: the work was valuable any how, because master now has an accurate
record of history.)
On 7 May 2013 20:01, Dave Cottlehuber <dc...@jsonified.com> wrote:
> On 7 May 2013 20:34, Noah Slater <ns...@apache.org> wrote:
>
> > Devs,
> >
> > We're switching over to time-based releases.
> >
> > I took a moment to review our existing release branches today, and I have
> > prepared a list of recommendations for you. Please review these and give
> me
> > feedback.
> >
> > By "drop support" I mean "make official" and while this is ostensibly the
> > case for a few of these, what I _really_ mean is "delete the branch". I
> see
> > no reason to keep this stuff around. It would make my life a lot easier
> if
> > we could clean this stuff up.
> >
> > I'm not a Git expert, so I am relying on someone to sanity check this.
> > Remember: if we ever want to patch up a security issue in an unsupported
> > release, we will be issuing a patch. So I am assuming what we'll want to
> do
> > is patch against the last tag for that release line. No need for the
> branch
> > at all as far as I can tell.
> >
> > If nobody objects in 72 hours, I will assume lazy consensus and proceed.
> >
> > ## 0.10.x line and before
> >
> > Really old stuff.
> >
> > Recommendation:
> >
> > * Drop support of these release lines
> > * Delete the branches
> >
> > ## 0.11.x line
> >
> > First release: March 2010 (three years old)
> >
> > Unreleased changes:
> >
> > * Fix for frequently edited documents in multi-master deployments being
> > duplicated in _changes and _all_docs.
> >
> > Recommendation:
> >
> > * Do not release these changes
> > * Drop support of this release line
> > * Delete the branch
> >
> > ## 1.0.x line
> >
> > First release: July 2010 (three years old)
> >
> > No unreleased changes.
> >
> > Recommendation:
> >
> > * Drop support of this release line
> > * Delete the branch
> >
> > ## 1.1.x line
> >
> > First release: July 2011 (two years old)
> >
> > No unreleased changes.
> >
> > Recommendation:
> >
> > * Drop support of this release line
> > * Delete the branch
> >
> > ## 1.2.x line
> >
> > First release: April 2012 (one year old)
> >
> > No unreleased changes.
> >
> > 1.3.x line is backwards compatible with 1.2.x.
> >
> > Recommendation:
> >
> > * Drop support of this release line
> > * Delete the branch
> >
> > ## 1.3.x line
> >
> > First release: April 2013 (one month old)
> >
> > Unreleased changes:
> >
> > * Whatever bugfixes are on master or in branches right now.
> >
> > Recommendation:
> >
> > * Release 1.3.1 this month.
> >
> > Thanks,
> >
> > --
> > NS
> >
>
> +1.
>
> You might consider tagging the last commit in each branch before you dump
> it. e.g. you have all those nice changes in NEWS/CHANGES etc that you
> slaved away on, in the above proposal they'd be lost.
>
--
NS
Re: [DISCUSS] Release clean-up (delete ALL the branches!)
Posted by Noah Slater <ns...@apache.org>.
Ah, well. Who cares, right? Just a bit more entropy for the Universe to
suck up.
On 7 May 2013 20:01, Dave Cottlehuber <dc...@jsonified.com> wrote:
> On 7 May 2013 20:34, Noah Slater <ns...@apache.org> wrote:
>
> > Devs,
> >
> > We're switching over to time-based releases.
> >
> > I took a moment to review our existing release branches today, and I have
> > prepared a list of recommendations for you. Please review these and give
> me
> > feedback.
> >
> > By "drop support" I mean "make official" and while this is ostensibly the
> > case for a few of these, what I _really_ mean is "delete the branch". I
> see
> > no reason to keep this stuff around. It would make my life a lot easier
> if
> > we could clean this stuff up.
> >
> > I'm not a Git expert, so I am relying on someone to sanity check this.
> > Remember: if we ever want to patch up a security issue in an unsupported
> > release, we will be issuing a patch. So I am assuming what we'll want to
> do
> > is patch against the last tag for that release line. No need for the
> branch
> > at all as far as I can tell.
> >
> > If nobody objects in 72 hours, I will assume lazy consensus and proceed.
> >
> > ## 0.10.x line and before
> >
> > Really old stuff.
> >
> > Recommendation:
> >
> > * Drop support of these release lines
> > * Delete the branches
> >
> > ## 0.11.x line
> >
> > First release: March 2010 (three years old)
> >
> > Unreleased changes:
> >
> > * Fix for frequently edited documents in multi-master deployments being
> > duplicated in _changes and _all_docs.
> >
> > Recommendation:
> >
> > * Do not release these changes
> > * Drop support of this release line
> > * Delete the branch
> >
> > ## 1.0.x line
> >
> > First release: July 2010 (three years old)
> >
> > No unreleased changes.
> >
> > Recommendation:
> >
> > * Drop support of this release line
> > * Delete the branch
> >
> > ## 1.1.x line
> >
> > First release: July 2011 (two years old)
> >
> > No unreleased changes.
> >
> > Recommendation:
> >
> > * Drop support of this release line
> > * Delete the branch
> >
> > ## 1.2.x line
> >
> > First release: April 2012 (one year old)
> >
> > No unreleased changes.
> >
> > 1.3.x line is backwards compatible with 1.2.x.
> >
> > Recommendation:
> >
> > * Drop support of this release line
> > * Delete the branch
> >
> > ## 1.3.x line
> >
> > First release: April 2013 (one month old)
> >
> > Unreleased changes:
> >
> > * Whatever bugfixes are on master or in branches right now.
> >
> > Recommendation:
> >
> > * Release 1.3.1 this month.
> >
> > Thanks,
> >
> > --
> > NS
> >
>
> +1.
>
> You might consider tagging the last commit in each branch before you dump
> it. e.g. you have all those nice changes in NEWS/CHANGES etc that you
> slaved away on, in the above proposal they'd be lost.
>
--
NS
Re: [DISCUSS] Release clean-up (delete ALL the branches!)
Posted by Dave Cottlehuber <dc...@jsonified.com>.
On 7 May 2013 20:34, Noah Slater <ns...@apache.org> wrote:
> Devs,
>
> We're switching over to time-based releases.
>
> I took a moment to review our existing release branches today, and I have
> prepared a list of recommendations for you. Please review these and give me
> feedback.
>
> By "drop support" I mean "make official" and while this is ostensibly the
> case for a few of these, what I _really_ mean is "delete the branch". I see
> no reason to keep this stuff around. It would make my life a lot easier if
> we could clean this stuff up.
>
> I'm not a Git expert, so I am relying on someone to sanity check this.
> Remember: if we ever want to patch up a security issue in an unsupported
> release, we will be issuing a patch. So I am assuming what we'll want to do
> is patch against the last tag for that release line. No need for the branch
> at all as far as I can tell.
>
> If nobody objects in 72 hours, I will assume lazy consensus and proceed.
>
> ## 0.10.x line and before
>
> Really old stuff.
>
> Recommendation:
>
> * Drop support of these release lines
> * Delete the branches
>
> ## 0.11.x line
>
> First release: March 2010 (three years old)
>
> Unreleased changes:
>
> * Fix for frequently edited documents in multi-master deployments being
> duplicated in _changes and _all_docs.
>
> Recommendation:
>
> * Do not release these changes
> * Drop support of this release line
> * Delete the branch
>
> ## 1.0.x line
>
> First release: July 2010 (three years old)
>
> No unreleased changes.
>
> Recommendation:
>
> * Drop support of this release line
> * Delete the branch
>
> ## 1.1.x line
>
> First release: July 2011 (two years old)
>
> No unreleased changes.
>
> Recommendation:
>
> * Drop support of this release line
> * Delete the branch
>
> ## 1.2.x line
>
> First release: April 2012 (one year old)
>
> No unreleased changes.
>
> 1.3.x line is backwards compatible with 1.2.x.
>
> Recommendation:
>
> * Drop support of this release line
> * Delete the branch
>
> ## 1.3.x line
>
> First release: April 2013 (one month old)
>
> Unreleased changes:
>
> * Whatever bugfixes are on master or in branches right now.
>
> Recommendation:
>
> * Release 1.3.1 this month.
>
> Thanks,
>
> --
> NS
>
+1.
You might consider tagging the last commit in each branch before you dump
it. e.g. you have all those nice changes in NEWS/CHANGES etc that you
slaved away on, in the above proposal they'd be lost.
Re: [DISCUSS] Release clean-up (delete ALL the branches!)
Posted by Noah Slater <ns...@apache.org>.
Thanks Alex. These should point to tags. I'll update them.
On 23 May 2013 10:34, Alexander Shorin <kx...@gmail.com> wrote:
> Side effect note: links on old blog posts are broken. Example:
> https://blogs.apache.org/couchdb/entry/apache_couchdb_1_2_0
>
> NEWS:
> http://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=blob_plain;f=NEWS;hb=1.2.x
> CHANGES:
> https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=blob_plain;f=CHANGES;hb=1.2.x
> git commit log:
> https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=log;h=1.2.x
> --
> ,,,^..^,,,
>
>
> On Tue, May 21, 2013 at 9:29 PM, Noah Slater <ns...@apache.org> wrote:
> > On 21 May 2013 18:05, Jan Lehnardt <ja...@apache.org> wrote:
> >
> >>
> >> On May 21, 2013, at 18:30 , Noah Slater <ns...@apache.org> wrote:
> >>
> >> > I don't want that either. Let's roll with the punches here and see
> what
> >> > happens. If people ask us what the situation is, we say the
> recommended
> >> > upgrade path is 1.2.2 -> 1.3.x. If we run into problems with that,
> lets
> >> > deal with it at that point. One option is to release actual patches
> that
> >> > you can apply to the 1.2.2 tag. Or we could just do another release.
> >> >
> >> > And yep, I updated that page to better reflect the discussion around
> the
> >> > roadmap process. [1] This moves our support plan to one that is both
> time
> >> > based and centred around major release lines. This works well with
> >> semver.
> >> > The promise is that every major version is supported (i.e. we add
> >> features
> >> > and bug fixes) for 12 months. That is easy to understand.
> >>
> >> I understand all that, I just don’t like the idea that we change rules
> >> from under a release that we did promise at release time to support for
> >> 12 months.
> >>
> >
> > I don't think we've ever made a 12 month promise before. The wiki diff
> you
> > linked to doesn't mention a timeline, it just mentions we'll support n-1.
> > So, I guess, technically, yes, we're breaking a promise. I'm just not
> > convinced that it's a very important promise. ;)
> >
> > Yes, and going forward that is all great, but the differences between
> 1.2.x
> >> and 1.3.x may warrant a new major version under the new regime (which
> again
> >> I do support), I just don’t like new rules applied to old releases.
> >
> >
> > Okay, sure. As you can see from the original thread, I was a
> > little hesitant to do this, because I didn't understand the complexities
> of
> > the 1.2.x -> 1.3.x migration (this being the first switchover to our new
> > system). In many respects, a little bit of friction/pain is unsurprising.
> >
> >> For 1.2.x and older lines, I went through them one by one in the
> original
> >> > email in this thread, to see a) how old they were and b) what the
> upgrade
> >> > path was. Based on that work, 1.1.x is two years old, so I suggested
> we
> >> > drop it. And 1.2.x is both one year old, and has an (though it seems
> this
> >> > isn't as clear cut as we thought) upgrade path to 1.3.x.
> >>
> >> Yes, and that makes the least sense to me. At the time of the release of
> >> 1.2.2 we stated that we support that release for 12 months earlier
> *this*
> >> year.
> >
> >
> > Hmm. Where? I don't think we ever said that. The promise was "n-1".
> Which I
> > agree we're breaking. I just don't think it's important, because of the
> > likely 1.2.x -> 1.3.x upgrade path. (I agree, if this isn't a legitimate
> > upgrade path, then this is a problem. It seems we don't know for sure
> > though — hence my suggestion to wait and see.)
> >
> >
> >> Or more concretely, if you buy some household device with a two year
> >> warranty and three months in the manufacturer decides to stop supporting
> >> it from now on. — I understand we don’t have a legal contract with our
> >> users, but we have a trust relationship here that we potentially damage.
> >>
> >
> > Agreed. I understand your metaphors. :) I don't want to damage trust
> > either. I think if there are legitimate problems moving from 1.2.2 to
> 1.3.0
> > then we absolutely handle that and support our users. If not, then we
> > should be able to say "please move to 1.3.0."
> >
> > I think this boils down to not wanting to apply new rules to old releases
> >> that were done when other rules were applicable. Is that at least a
> little
> >> bit understandable?
> >>
> >
> > Absolutely.
> >
> >
> >> Also, I believe we already have spent entirely too much time on this. I
> >> don’t want to turn this into a who is right and who is righter endless-
> >> thread. I understand how we arrived at the current situation and I don’t
> >> think anyone in particular is to blame for this. I just think the wrong
> >> decision was made with regards to existing supported releases and I
> think
> >> the proposed plan (resurrect 1.2.x when/if required) is enough to let
> >> this rest for now until a situation arises that requires us to look
> >> at 1.2.x.
> >>
> >
> > Cool. Sorry if you thought the thread was headed in that direction. I
> think
> > this is a healthy conversation to be having. And I think we've both made
> > reasonable arguments, and ended up in agreement. :)
> >
> > --
> > NS
>
--
NS
Re: [DISCUSS] Release clean-up (delete ALL the branches!)
Posted by Alexander Shorin <kx...@gmail.com>.
Side effect note: links on old blog posts are broken. Example:
https://blogs.apache.org/couchdb/entry/apache_couchdb_1_2_0
NEWS: http://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=blob_plain;f=NEWS;hb=1.2.x
CHANGES: https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=blob_plain;f=CHANGES;hb=1.2.x
git commit log:
https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=log;h=1.2.x
--
,,,^..^,,,
On Tue, May 21, 2013 at 9:29 PM, Noah Slater <ns...@apache.org> wrote:
> On 21 May 2013 18:05, Jan Lehnardt <ja...@apache.org> wrote:
>
>>
>> On May 21, 2013, at 18:30 , Noah Slater <ns...@apache.org> wrote:
>>
>> > I don't want that either. Let's roll with the punches here and see what
>> > happens. If people ask us what the situation is, we say the recommended
>> > upgrade path is 1.2.2 -> 1.3.x. If we run into problems with that, lets
>> > deal with it at that point. One option is to release actual patches that
>> > you can apply to the 1.2.2 tag. Or we could just do another release.
>> >
>> > And yep, I updated that page to better reflect the discussion around the
>> > roadmap process. [1] This moves our support plan to one that is both time
>> > based and centred around major release lines. This works well with
>> semver.
>> > The promise is that every major version is supported (i.e. we add
>> features
>> > and bug fixes) for 12 months. That is easy to understand.
>>
>> I understand all that, I just don’t like the idea that we change rules
>> from under a release that we did promise at release time to support for
>> 12 months.
>>
>
> I don't think we've ever made a 12 month promise before. The wiki diff you
> linked to doesn't mention a timeline, it just mentions we'll support n-1.
> So, I guess, technically, yes, we're breaking a promise. I'm just not
> convinced that it's a very important promise. ;)
>
> Yes, and going forward that is all great, but the differences between 1.2.x
>> and 1.3.x may warrant a new major version under the new regime (which again
>> I do support), I just don’t like new rules applied to old releases.
>
>
> Okay, sure. As you can see from the original thread, I was a
> little hesitant to do this, because I didn't understand the complexities of
> the 1.2.x -> 1.3.x migration (this being the first switchover to our new
> system). In many respects, a little bit of friction/pain is unsurprising.
>
>> For 1.2.x and older lines, I went through them one by one in the original
>> > email in this thread, to see a) how old they were and b) what the upgrade
>> > path was. Based on that work, 1.1.x is two years old, so I suggested we
>> > drop it. And 1.2.x is both one year old, and has an (though it seems this
>> > isn't as clear cut as we thought) upgrade path to 1.3.x.
>>
>> Yes, and that makes the least sense to me. At the time of the release of
>> 1.2.2 we stated that we support that release for 12 months earlier *this*
>> year.
>
>
> Hmm. Where? I don't think we ever said that. The promise was "n-1". Which I
> agree we're breaking. I just don't think it's important, because of the
> likely 1.2.x -> 1.3.x upgrade path. (I agree, if this isn't a legitimate
> upgrade path, then this is a problem. It seems we don't know for sure
> though — hence my suggestion to wait and see.)
>
>
>> Or more concretely, if you buy some household device with a two year
>> warranty and three months in the manufacturer decides to stop supporting
>> it from now on. — I understand we don’t have a legal contract with our
>> users, but we have a trust relationship here that we potentially damage.
>>
>
> Agreed. I understand your metaphors. :) I don't want to damage trust
> either. I think if there are legitimate problems moving from 1.2.2 to 1.3.0
> then we absolutely handle that and support our users. If not, then we
> should be able to say "please move to 1.3.0."
>
> I think this boils down to not wanting to apply new rules to old releases
>> that were done when other rules were applicable. Is that at least a little
>> bit understandable?
>>
>
> Absolutely.
>
>
>> Also, I believe we already have spent entirely too much time on this. I
>> don’t want to turn this into a who is right and who is righter endless-
>> thread. I understand how we arrived at the current situation and I don’t
>> think anyone in particular is to blame for this. I just think the wrong
>> decision was made with regards to existing supported releases and I think
>> the proposed plan (resurrect 1.2.x when/if required) is enough to let
>> this rest for now until a situation arises that requires us to look
>> at 1.2.x.
>>
>
> Cool. Sorry if you thought the thread was headed in that direction. I think
> this is a healthy conversation to be having. And I think we've both made
> reasonable arguments, and ended up in agreement. :)
>
> --
> NS
Re: [DISCUSS] Release clean-up (delete ALL the branches!)
Posted by Noah Slater <ns...@apache.org>.
On 21 May 2013 18:05, Jan Lehnardt <ja...@apache.org> wrote:
>
> On May 21, 2013, at 18:30 , Noah Slater <ns...@apache.org> wrote:
>
> > I don't want that either. Let's roll with the punches here and see what
> > happens. If people ask us what the situation is, we say the recommended
> > upgrade path is 1.2.2 -> 1.3.x. If we run into problems with that, lets
> > deal with it at that point. One option is to release actual patches that
> > you can apply to the 1.2.2 tag. Or we could just do another release.
> >
> > And yep, I updated that page to better reflect the discussion around the
> > roadmap process. [1] This moves our support plan to one that is both time
> > based and centred around major release lines. This works well with
> semver.
> > The promise is that every major version is supported (i.e. we add
> features
> > and bug fixes) for 12 months. That is easy to understand.
>
> I understand all that, I just don’t like the idea that we change rules
> from under a release that we did promise at release time to support for
> 12 months.
>
I don't think we've ever made a 12 month promise before. The wiki diff you
linked to doesn't mention a timeline, it just mentions we'll support n-1.
So, I guess, technically, yes, we're breaking a promise. I'm just not
convinced that it's a very important promise. ;)
Yes, and going forward that is all great, but the differences between 1.2.x
> and 1.3.x may warrant a new major version under the new regime (which again
> I do support), I just don’t like new rules applied to old releases.
Okay, sure. As you can see from the original thread, I was a
little hesitant to do this, because I didn't understand the complexities of
the 1.2.x -> 1.3.x migration (this being the first switchover to our new
system). In many respects, a little bit of friction/pain is unsurprising.
> For 1.2.x and older lines, I went through them one by one in the original
> > email in this thread, to see a) how old they were and b) what the upgrade
> > path was. Based on that work, 1.1.x is two years old, so I suggested we
> > drop it. And 1.2.x is both one year old, and has an (though it seems this
> > isn't as clear cut as we thought) upgrade path to 1.3.x.
>
> Yes, and that makes the least sense to me. At the time of the release of
> 1.2.2 we stated that we support that release for 12 months earlier *this*
> year.
Hmm. Where? I don't think we ever said that. The promise was "n-1". Which I
agree we're breaking. I just don't think it's important, because of the
likely 1.2.x -> 1.3.x upgrade path. (I agree, if this isn't a legitimate
upgrade path, then this is a problem. It seems we don't know for sure
though — hence my suggestion to wait and see.)
> Or more concretely, if you buy some household device with a two year
> warranty and three months in the manufacturer decides to stop supporting
> it from now on. — I understand we don’t have a legal contract with our
> users, but we have a trust relationship here that we potentially damage.
>
Agreed. I understand your metaphors. :) I don't want to damage trust
either. I think if there are legitimate problems moving from 1.2.2 to 1.3.0
then we absolutely handle that and support our users. If not, then we
should be able to say "please move to 1.3.0."
I think this boils down to not wanting to apply new rules to old releases
> that were done when other rules were applicable. Is that at least a little
> bit understandable?
>
Absolutely.
> Also, I believe we already have spent entirely too much time on this. I
> don’t want to turn this into a who is right and who is righter endless-
> thread. I understand how we arrived at the current situation and I don’t
> think anyone in particular is to blame for this. I just think the wrong
> decision was made with regards to existing supported releases and I think
> the proposed plan (resurrect 1.2.x when/if required) is enough to let
> this rest for now until a situation arises that requires us to look
> at 1.2.x.
>
Cool. Sorry if you thought the thread was headed in that direction. I think
this is a healthy conversation to be having. And I think we've both made
reasonable arguments, and ended up in agreement. :)
--
NS
Re: [DISCUSS] Release clean-up (delete ALL the branches!)
Posted by Jan Lehnardt <ja...@apache.org>.
On May 21, 2013, at 18:30 , Noah Slater <ns...@apache.org> wrote:
> I don't want that either. Let's roll with the punches here and see what
> happens. If people ask us what the situation is, we say the recommended
> upgrade path is 1.2.2 -> 1.3.x. If we run into problems with that, lets
> deal with it at that point. One option is to release actual patches that
> you can apply to the 1.2.2 tag. Or we could just do another release.
>
> And yep, I updated that page to better reflect the discussion around the
> roadmap process. [1] This moves our support plan to one that is both time
> based and centred around major release lines. This works well with semver.
> The promise is that every major version is supported (i.e. we add features
> and bug fixes) for 12 months. That is easy to understand.
I understand all that, I just don’t like the idea that we change rules
from under a release that we did promise at release time to support for
12 months.
> Note also how great this is for our release procedure. Before we've been
> running 1.1.x, and 1.2.x at the same time. Not for any particular reason.
> Just because. We were doing it even if there were no breaking changes!
> Nonsensical. Dale's original email was so great. I can't believe I never
> realised this before in the half a decade I've been cutting releases. Heh.
Yes, and going forward that is all great, but the differences between 1.2.x
and 1.3.x may warrant a new major version under the new regime (which again
I do support), I just don’t like new rules applied to old releases.
> For 1.2.x and older lines, I went through them one by one in the original
> email in this thread, to see a) how old they were and b) what the upgrade
> path was. Based on that work, 1.1.x is two years old, so I suggested we
> drop it. And 1.2.x is both one year old, and has an (though it seems this
> isn't as clear cut as we thought) upgrade path to 1.3.x.
Yes, and that makes the least sense to me. At the time of the release of
1.2.2 we stated that we support that release for 12 months earlier *this*
year. So if we are looking at a transition, and if we were wanting to try
to not break any promises we made just a few months ago, I’d look at the
*latest* release in a particular line and nuke everything older than 12
months (now that’d include the 1.1.x line, but I’d be in favour of
retiring that, as the last fix was as security fix).
This whole argument reads to me like deciding that a tax rate of 50% is
raised to 75% retroactively to five years ago and all individuals and
businesses need to pay the missing 25% retroactively. I understand that
there are some backdating situations in the real world, but they are
rarely as substantial. All I am in favour of is using the 75% tax
*from now on*, so everyone can adjust their accounting accordingly.
Or more concretely, if you buy some household device with a two year
warranty and three months in the manufacturer decides to stop supporting
it from now on. — I understand we don’t have a legal contract with our
users, but we have a trust relationship here that we potentially damage.
I think this boils down to not wanting to apply new rules to old releases
that were done when other rules were applicable. Is that at least a little
bit understandable?
Also, I believe we already have spent entirely too much time on this. I
don’t want to turn this into a who is right and who is righter endless-
thread. I understand how we arrived at the current situation and I don’t
think anyone in particular is to blame for this. I just think the wrong
decision was made with regards to existing supported releases and I think
the proposed plan (resurrect 1.2.x when/if required) is enough to let
this rest for now until a situation arises that requires us to look
at 1.2.x.
Jan
--
>
> [1] http://wiki.apache.org/couchdb/Roadmap_Process
>
>
> On 21 May 2013 17:12, Jan Lehnardt <ja...@apache.org> wrote:
>
>>
>> On May 21, 2013, at 17:31 , Noah Slater <ns...@apache.org> wrote:
>>
>>> On 21 May 2013 16:05, Jan Lehnardt <ja...@apache.org> wrote:
>>>
>>>>
>>>> Again, I missed this and the vote due to vacation and I only skimmed
>>>> the thread in catch-up mode.
>>>>
>>>
>>> Understood. I was providing you with context.
>>
>> Yup, cheers :)
>>
>>
>>>>> I've also made an adjustment to the "n + n-1" concept, more inline with
>>>>> both the Dublin discussion and the points about semver that Dale
>> brought
>>>>> up, and I added it to the wiki, as previously noted in this thread.
>>>>
>>>> We can’ retroactively do that for releases that aren’t part of the new
>>>> plan (e.g. 1.2.x) where the circumstances of strict semver don’t apply.
>>>>
>>>
>>> We can, because all I'm suggesting is:
>>>
>>> * We identify each release line that is not upgradable to the next, and
>>> * That we support these release lines for 12 months
>>>
>>> This strategy works no matter what versioning system we use.
>>>
>>>> I agree to do this going forward, but I found it odd to drop a branch
>> that
>>>> we currently consider as being supported, that is all.
>>>>
>>>
>>> I dropped it because we decided not to support it.
>>>
>>>
>>>> I stand by my previous suggestion to resurrect 1.2.x in case we need to
>> do
>>>> a follow-up release if the scenario warrants that a user can’t upgrade
>> to
>>>> 1.3.x.
>>>>
>>>
>>> There is no indication in 1.3.x that there are breaking changes over
>> 1.2.x.
>>> How likely is it, do you think, that there is legitimate reason not to
>>> upgrade?
>>>
>>> Moreover, even the upgrade path from 1.2.x to 1.3.x is problematic, the
>>> 1.2.x line is now 12 months old, so according to our 12 months support
>>> plan, it is time that we drop support anyway.
>>
>>
>> So we made the decision to support major release lines instead of just
>> single
>> releases?[1] Again, I am all game with that going forward, but we released
>> 1.2.2
>> earlier this year under the premise that that *release* was supported for
>> 12
>> months, not just the 1.2.x line.
>>
>> I just imagine the scenario as a user on the 1.2.2 release, having
>> installed
>> it with the premise that we’d support that particular release for 12 months
>> only to find out that we drop support for it after just a few month
>> claiming
>> new rules.
>>
>> I’m not saying we can’t do that, we can do whatever the hell we want, but I
>> don’t like the idea that our uses can get into a situation where they feel
>> screwed over.
>>
>> Jan
>> --
>> [1]:
>> http://wiki.apache.org/couchdb/CurrentReleases?action=diff&rev2=27&rev1=22
>
>
>
>
> --
> NS
Re: [DISCUSS] Release clean-up (delete ALL the branches!)
Posted by Noah Slater <ns...@apache.org>.
I don't want that either. Let's roll with the punches here and see what
happens. If people ask us what the situation is, we say the recommended
upgrade path is 1.2.2 -> 1.3.x. If we run into problems with that, lets
deal with it at that point. One option is to release actual patches that
you can apply to the 1.2.2 tag. Or we could just do another release.
And yep, I updated that page to better reflect the discussion around the
roadmap process. [1] This moves our support plan to one that is both time
based and centred around major release lines. This works well with semver.
The promise is that every major version is supported (i.e. we add features
and bug fixes) for 12 months. That is easy to understand.
Note also how great this is for our release procedure. Before we've been
running 1.1.x, and 1.2.x at the same time. Not for any particular reason.
Just because. We were doing it even if there were no breaking changes!
Nonsensical. Dale's original email was so great. I can't believe I never
realised this before in the half a decade I've been cutting releases. Heh.
For 1.2.x and older lines, I went through them one by one in the original
email in this thread, to see a) how old they were and b) what the upgrade
path was. Based on that work, 1.1.x is two years old, so I suggested we
drop it. And 1.2.x is both one year old, and has an (though it seems this
isn't as clear cut as we thought) upgrade path to 1.3.x.
[1] http://wiki.apache.org/couchdb/Roadmap_Process
On 21 May 2013 17:12, Jan Lehnardt <ja...@apache.org> wrote:
>
> On May 21, 2013, at 17:31 , Noah Slater <ns...@apache.org> wrote:
>
> > On 21 May 2013 16:05, Jan Lehnardt <ja...@apache.org> wrote:
> >
> >>
> >> Again, I missed this and the vote due to vacation and I only skimmed
> >> the thread in catch-up mode.
> >>
> >
> > Understood. I was providing you with context.
>
> Yup, cheers :)
>
>
> >>> I've also made an adjustment to the "n + n-1" concept, more inline with
> >>> both the Dublin discussion and the points about semver that Dale
> brought
> >>> up, and I added it to the wiki, as previously noted in this thread.
> >>
> >> We can’ retroactively do that for releases that aren’t part of the new
> >> plan (e.g. 1.2.x) where the circumstances of strict semver don’t apply.
> >>
> >
> > We can, because all I'm suggesting is:
> >
> > * We identify each release line that is not upgradable to the next, and
> > * That we support these release lines for 12 months
> >
> > This strategy works no matter what versioning system we use.
> >
> >> I agree to do this going forward, but I found it odd to drop a branch
> that
> >> we currently consider as being supported, that is all.
> >>
> >
> > I dropped it because we decided not to support it.
> >
> >
> >> I stand by my previous suggestion to resurrect 1.2.x in case we need to
> do
> >> a follow-up release if the scenario warrants that a user can’t upgrade
> to
> >> 1.3.x.
> >>
> >
> > There is no indication in 1.3.x that there are breaking changes over
> 1.2.x.
> > How likely is it, do you think, that there is legitimate reason not to
> > upgrade?
> >
> > Moreover, even the upgrade path from 1.2.x to 1.3.x is problematic, the
> > 1.2.x line is now 12 months old, so according to our 12 months support
> > plan, it is time that we drop support anyway.
>
>
> So we made the decision to support major release lines instead of just
> single
> releases?[1] Again, I am all game with that going forward, but we released
> 1.2.2
> earlier this year under the premise that that *release* was supported for
> 12
> months, not just the 1.2.x line.
>
> I just imagine the scenario as a user on the 1.2.2 release, having
> installed
> it with the premise that we’d support that particular release for 12 months
> only to find out that we drop support for it after just a few month
> claiming
> new rules.
>
> I’m not saying we can’t do that, we can do whatever the hell we want, but I
> don’t like the idea that our uses can get into a situation where they feel
> screwed over.
>
> Jan
> --
> [1]:
> http://wiki.apache.org/couchdb/CurrentReleases?action=diff&rev2=27&rev1=22
--
NS
Re: [DISCUSS] Release clean-up (delete ALL the branches!)
Posted by Jan Lehnardt <ja...@apache.org>.
On May 21, 2013, at 17:31 , Noah Slater <ns...@apache.org> wrote:
> On 21 May 2013 16:05, Jan Lehnardt <ja...@apache.org> wrote:
>
>>
>> Again, I missed this and the vote due to vacation and I only skimmed
>> the thread in catch-up mode.
>>
>
> Understood. I was providing you with context.
Yup, cheers :)
>>> I've also made an adjustment to the "n + n-1" concept, more inline with
>>> both the Dublin discussion and the points about semver that Dale brought
>>> up, and I added it to the wiki, as previously noted in this thread.
>>
>> We can’ retroactively do that for releases that aren’t part of the new
>> plan (e.g. 1.2.x) where the circumstances of strict semver don’t apply.
>>
>
> We can, because all I'm suggesting is:
>
> * We identify each release line that is not upgradable to the next, and
> * That we support these release lines for 12 months
>
> This strategy works no matter what versioning system we use.
>
>> I agree to do this going forward, but I found it odd to drop a branch that
>> we currently consider as being supported, that is all.
>>
>
> I dropped it because we decided not to support it.
>
>
>> I stand by my previous suggestion to resurrect 1.2.x in case we need to do
>> a follow-up release if the scenario warrants that a user can’t upgrade to
>> 1.3.x.
>>
>
> There is no indication in 1.3.x that there are breaking changes over 1.2.x.
> How likely is it, do you think, that there is legitimate reason not to
> upgrade?
>
> Moreover, even the upgrade path from 1.2.x to 1.3.x is problematic, the
> 1.2.x line is now 12 months old, so according to our 12 months support
> plan, it is time that we drop support anyway.
So we made the decision to support major release lines instead of just single
releases?[1] Again, I am all game with that going forward, but we released 1.2.2
earlier this year under the premise that that *release* was supported for 12
months, not just the 1.2.x line.
I just imagine the scenario as a user on the 1.2.2 release, having installed
it with the premise that we’d support that particular release for 12 months
only to find out that we drop support for it after just a few month claiming
new rules.
I’m not saying we can’t do that, we can do whatever the hell we want, but I
don’t like the idea that our uses can get into a situation where they feel
screwed over.
Jan
--
[1]: http://wiki.apache.org/couchdb/CurrentReleases?action=diff&rev2=27&rev1=22
Re: [DISCUSS] Release clean-up (delete ALL the branches!)
Posted by Noah Slater <ns...@apache.org>.
On 21 May 2013 16:05, Jan Lehnardt <ja...@apache.org> wrote:
>
> Again, I missed this and the vote due to vacation and I only skimmed
> the thread in catch-up mode.
>
Understood. I was providing you with context.
> > I've also made an adjustment to the "n + n-1" concept, more inline with
> > both the Dublin discussion and the points about semver that Dale brought
> > up, and I added it to the wiki, as previously noted in this thread.
>
> We can’ retroactively do that for releases that aren’t part of the new
> plan (e.g. 1.2.x) where the circumstances of strict semver don’t apply.
>
We can, because all I'm suggesting is:
* We identify each release line that is not upgradable to the next, and
* That we support these release lines for 12 months
This strategy works no matter what versioning system we use.
I agree to do this going forward, but I found it odd to drop a branch that
> we currently consider as being supported, that is all.
>
I dropped it because we decided not to support it.
I stand by my previous suggestion to resurrect 1.2.x in case we need to do
> a follow-up release if the scenario warrants that a user can’t upgrade to
> 1.3.x.
>
There is no indication in 1.3.x that there are breaking changes over 1.2.x.
How likely is it, do you think, that there is legitimate reason not to
upgrade?
Moreover, even the upgrade path from 1.2.x to 1.3.x is problematic, the
1.2.x line is now 12 months old, so according to our 12 months support
plan, it is time that we drop support anyway.
--
NS
Re: [DISCUSS] Release clean-up (delete ALL the branches!)
Posted by Jan Lehnardt <ja...@apache.org>.
On May 21, 2013, at 15:20 , Noah Slater <ns...@apache.org> wrote:
> This was discussed in the following thread:
>
> "[DISCUSS] Simplify active release branches (Was: Re: [DISCUSS] Git
> workflow)"
Again, I missed this and the vote due to vacation and I only skimmed
the thread in catch-up mode.
> — http://markmail.org/message/5edirnhli43g7lt6
>
> At the start of this thread, I put forward my rationale for dropping
> support for 1.2.x (namely, that 1.3.x should be forwards compatible with
> 1.2.x), and nobody objected.
I formally object now.
> I've also made an adjustment to the "n + n-1" concept, more inline with
> both the Dublin discussion and the points about semver that Dale brought
> up, and I added it to the wiki, as previously noted in this thread.
We can’ retroactively do that for releases that aren’t part of the new
plan (e.g. 1.2.x) where the circumstances of strict semver don’t apply.
>
> We will support each major version for 12 months. So, if 1.0.0 was released
>> on 2010-01-01, then we would add features and fixes to it until 2011-01-01.
>> After 12 months have passed, we may continue to release fixes for critical
>> security issues, but these will be in the form of actual patches.
>
>
>
> Note that the upgrade path for minor versions is to update the latest minor
>> version. We will not continue to release patch versions for an old minor
>> version. That is, 1.1.0 immediately supersedes 1.0.x, and no more fixes
>> will be made on the 1.0.x line. Similarly, 1.2.0 immediately supersedes
>> 1.1.x.
>
>
> — http://wiki.apache.org/couchdb/CurrentReleases
>
> I appreciate that this is the first time we've done this, so it might be a
> little surprising to people. (Though, I believe, this has been the plan for
> a good 12 months.) Let's closely monitor the situation, and if any issues
> crop up, we deal with them.
I agree to do this going forward, but I found it odd to drop a branch that
we currently consider as being supported, that is all.
I stand by my previous suggestion to resurrect 1.2.x in case we need to do
a follow-up release if the scenario warrants that a user can’t upgrade to
1.3.x.
Jan
--
>
>
> On 21 May 2013 10:31, Jan Lehnardt <ja...@apache.org> wrote:
>
>>
>> On May 21, 2013, at 08:32 , Benoit Chesneau <bc...@gmail.com> wrote:
>>
>>> I thought we needed to support n and n-1. Did that change?
>>
>> It was my impression that that’s what we agreed on, as well.
>>
>> While 1.2.x -> 1.3.x is the recommended upgrade line, we pledged to
>> do bugfixes and security issues for 1.2.x. Especially given that the
>> view engine got a bit of a revamp, I could conceive of a situation
>> where users wouldn’t want to make the jump to 1.3.x just yet.
>>
>> In a post 1.3.x strict-semver, we should have less of that, but for
>> now I think it is wise to keep 1.2.x up (that said, we can resurrect
>> the branch at any time, so we may as well leave it out until needed).
>>
>> Jan
>> --
>>
>>
>>
>>>
>>> - benoît
>>> On May 21, 2013 3:43 AM, "Noah Slater" <ns...@apache.org> wrote:
>>>
>>>> Nope. 1.2.x is no longer an actively supported branch. 1.3.x is forwards
>>>> compatible, and is the recommended upgrade path for anyone on 1.2.x.
>>>>
>>>>
>>>> On 20 May 2013 20:56, Jan Lehnardt <ja...@apache.org> wrote:
>>>>
>>>>> Eh sorry, I just noticed that broke CI for 1.2.x which is surely still
>> an
>>>>> actively supported branch, shouldn’t we keep that around?
>>>>>
>>>>> Jan
>>>>> --
>>>>>
>>>>> On May 18, 2013, at 22:24 , Jan Lehnardt <ja...@apache.org> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On 18.05.2013, at 19:56, Noah Slater <ns...@apache.org> wrote:
>>>>>>
>>>>>>> Based on the decision made in this thread, it would like to add
>>>>> something
>>>>>>> to the release procedure about deleting old branches when we drop
>>>>> support
>>>>>>> for that release line.
>>>>>>>
>>>>>>> As far as I understand it, no history is lost. The tags still point
>> to
>>>>> what
>>>>>>> we shipped, and the commits still exist in the repository We're just
>>>>>>> removing the pointers to the tips of the branches.
>>>>>>>
>>>>>>> Is this something I need to call another vote for, or am I free to
>> add
>>>>> it?
>>>>>>
>>>>>> Go for it.
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 18 May 2013 18:50, Jan Lehnardt <ja...@apache.org> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 18.05.2013, at 18:43, Noah Slater <ns...@apache.org> wrote:
>>>>>>>>
>>>>>>>>> Unfortunately, the deed is done. What is your reason for wanting to
>>>>> keep
>>>>>>>>> them around?
>>>>>>>>
>>>>>>>> History :)
>>>>>>>>
>>>>>>>> I have plenty of clones, so no worries :)
>>>>>>>>
>>>>>>>> Jan
>>>>>>>> --
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 18 May 2013 18:38, Jan Lehnardt <ja...@apache.org> wrote:
>>>>>>>>>
>>>>>>>>>> Ah wow, that's what I get for going on vacation with unread
>>>> threads.
>>>>>>>>>>
>>>>>>>>>> I'm major -1 on deleting old release branches, but I'd be happy to
>>>>> have
>>>>>>>>>> them moved to an archived repository. For the time being, I'll
>> keep
>>>>>>>> them on
>>>>>>>>>> my GitHub.
>>>>>>>>>>
>>>>>>>>>> Cheers
>>>>>>>>>> Jan
>>>>>>>>>> --
>>>>>>>>>>
>>>>>>>>>> On 11.05.2013, at 17:31, Noah Slater <ns...@apache.org> wrote:
>>>>>>>>>>
>>>>>>>>>>> Thanks guys.
>>>>>>>>>>>
>>>>>>>>>>> All the Y.Y.x branches, with the exception of 1.3.x, have been
>>>>> deleted.
>>>>>>>>>>>
>>>>>>>>>>> The following releases have been archived:
>>>>>>>>>>>
>>>>>>>>>>> * 1.0.4
>>>>>>>>>>> * 1.1.2
>>>>>>>>>>> * 1.2.1
>>>>>>>>>>> * 1.2.2
>>>>>>>>>>>
>>>>>>>>>>> (Where archived means: removed from our wiki and dist dir.)
>>>>>>>>>>>
>>>>>>>>>>> I added the following to our CurrentReleases page:
>>>>>>>>>>>
>>>>>>>>>>> CouchDB uses [[http://semver.org/|semantic versioning]], so, in
>> a
>>>>>>>>>> nutshell:
>>>>>>>>>>>
>>>>>>>>>>> * X.Y.Z equates to major version, minor version, and bugfix
>>>> version.
>>>>>>>>>>> * The major version will be incremented every time we make
>>>> backwards
>>>>>>>>>>> incompatible changes.
>>>>>>>>>>> * The minor version will be incremented every time we add
>>>> backwards
>>>>>>>>>>> compatible features.
>>>>>>>>>>> * The patch version will be incremented every time we add
>>>> backwards
>>>>>>>>>>> compatible fixes.
>>>>>>>>>>>
>>>>>>>>>>> We will support each major version for 12 months. So, if 1.0.0
>> was
>>>>>>>>>> released
>>>>>>>>>>> on 2010-01-01, then we would features and fixes to it until
>>>>> 2011-01-01.
>>>>>>>>>>> After 12 months have passed, we may continue to release fixes for
>>>>>>>>>> critical
>>>>>>>>>>> security issues, but these will be in the form of patches.
>>>>>>>>>>>
>>>>>>>>>>> Note that the upgrade path for minor versions is to update the
>>>>> latest
>>>>>>>>>> minor
>>>>>>>>>>> version. We will not continue to release bugfix versions for an
>>>> old
>>>>>>>> minor
>>>>>>>>>>> version. That is, 1.1.0 immediately supersedes 1.0.x, and no more
>>>>> fixes
>>>>>>>>>>> will be made on the 1.0.x line. Similarly, 1.2.0 immediately
>>>>> supersedes
>>>>>>>>>>> 1.1.x.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 7 May 2013 19:34, Noah Slater <ns...@apache.org> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Devs,
>>>>>>>>>>>>
>>>>>>>>>>>> We're switching over to time-based releases.
>>>>>>>>>>>>
>>>>>>>>>>>> I took a moment to review our existing release branches today,
>>>> and
>>>>> I
>>>>>>>>>> have
>>>>>>>>>>>> prepared a list of recommendations for you. Please review these
>>>> and
>>>>>>>>>> give me
>>>>>>>>>>>> feedback.
>>>>>>>>>>>>
>>>>>>>>>>>> By "drop support" I mean "make official" and while this is
>>>>> ostensibly
>>>>>>>>>> the
>>>>>>>>>>>> case for a few of these, what I _really_ mean is "delete the
>>>>> branch".
>>>>>>>> I
>>>>>>>>>> see
>>>>>>>>>>>> no reason to keep this stuff around. It would make my life a lot
>>>>>>>> easier
>>>>>>>>>> if
>>>>>>>>>>>> we could clean this stuff up.
>>>>>>>>>>>>
>>>>>>>>>>>> I'm not a Git expert, so I am relying on someone to sanity check
>>>>> this.
>>>>>>>>>>>> Remember: if we ever want to patch up a security issue in an
>>>>>>>> unsupported
>>>>>>>>>>>> release, we will be issuing a patch. So I am assuming what we'll
>>>>> want
>>>>>>>>>> to do
>>>>>>>>>>>> is patch against the last tag for that release line. No need for
>>>>> the
>>>>>>>>>> branch
>>>>>>>>>>>> at all as far as I can tell.
>>>>>>>>>>>>
>>>>>>>>>>>> If nobody objects in 72 hours, I will assume lazy consensus and
>>>>>>>> proceed.
>>>>>>>>>>>>
>>>>>>>>>>>> ## 0.10.x line and before
>>>>>>>>>>>>
>>>>>>>>>>>> Really old stuff.
>>>>>>>>>>>>
>>>>>>>>>>>> Recommendation:
>>>>>>>>>>>>
>>>>>>>>>>>> * Drop support of these release lines
>>>>>>>>>>>> * Delete the branches
>>>>>>>>>>>>
>>>>>>>>>>>> ## 0.11.x line
>>>>>>>>>>>>
>>>>>>>>>>>> First release: March 2010 (three years old)
>>>>>>>>>>>>
>>>>>>>>>>>> Unreleased changes:
>>>>>>>>>>>>
>>>>>>>>>>>> * Fix for frequently edited documents in multi-master
>> deployments
>>>>>>>> being
>>>>>>>>>>>> duplicated in _changes and _all_docs.
>>>>>>>>>>>>
>>>>>>>>>>>> Recommendation:
>>>>>>>>>>>>
>>>>>>>>>>>> * Do not release these changes
>>>>>>>>>>>> * Drop support of this release line
>>>>>>>>>>>> * Delete the branch
>>>>>>>>>>>>
>>>>>>>>>>>> ## 1.0.x line
>>>>>>>>>>>>
>>>>>>>>>>>> First release: July 2010 (three years old)
>>>>>>>>>>>>
>>>>>>>>>>>> No unreleased changes.
>>>>>>>>>>>>
>>>>>>>>>>>> Recommendation:
>>>>>>>>>>>>
>>>>>>>>>>>> * Drop support of this release line
>>>>>>>>>>>> * Delete the branch
>>>>>>>>>>>>
>>>>>>>>>>>> ## 1.1.x line
>>>>>>>>>>>>
>>>>>>>>>>>> First release: July 2011 (two years old)
>>>>>>>>>>>>
>>>>>>>>>>>> No unreleased changes.
>>>>>>>>>>>>
>>>>>>>>>>>> Recommendation:
>>>>>>>>>>>>
>>>>>>>>>>>> * Drop support of this release line
>>>>>>>>>>>> * Delete the branch
>>>>>>>>>>>>
>>>>>>>>>>>> ## 1.2.x line
>>>>>>>>>>>>
>>>>>>>>>>>> First release: April 2012 (one year old)
>>>>>>>>>>>>
>>>>>>>>>>>> No unreleased changes.
>>>>>>>>>>>>
>>>>>>>>>>>> 1.3.x line is backwards compatible with 1.2.x.
>>>>>>>>>>>>
>>>>>>>>>>>> Recommendation:
>>>>>>>>>>>>
>>>>>>>>>>>> * Drop support of this release line
>>>>>>>>>>>> * Delete the branch
>>>>>>>>>>>>
>>>>>>>>>>>> ## 1.3.x line
>>>>>>>>>>>>
>>>>>>>>>>>> First release: April 2013 (one month old)
>>>>>>>>>>>>
>>>>>>>>>>>> Unreleased changes:
>>>>>>>>>>>>
>>>>>>>>>>>> * Whatever bugfixes are on master or in branches right now.
>>>>>>>>>>>>
>>>>>>>>>>>> Recommendation:
>>>>>>>>>>>>
>>>>>>>>>>>> * Release 1.3.1 this month.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> NS
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> NS
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> NS
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> NS
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> NS
>>>>
>>
>>
>
>
> --
> NS
Re: [DISCUSS] Release clean-up (delete ALL the branches!)
Posted by Noah Slater <ns...@apache.org>.
This was discussed in the following thread:
"[DISCUSS] Simplify active release branches (Was: Re: [DISCUSS] Git
workflow)"
— http://markmail.org/message/5edirnhli43g7lt6
At the start of this thread, I put forward my rationale for dropping
support for 1.2.x (namely, that 1.3.x should be forwards compatible with
1.2.x), and nobody objected.
I've also made an adjustment to the "n + n-1" concept, more inline with
both the Dublin discussion and the points about semver that Dale brought
up, and I added it to the wiki, as previously noted in this thread.
We will support each major version for 12 months. So, if 1.0.0 was released
> on 2010-01-01, then we would add features and fixes to it until 2011-01-01.
> After 12 months have passed, we may continue to release fixes for critical
> security issues, but these will be in the form of actual patches.
Note that the upgrade path for minor versions is to update the latest minor
> version. We will not continue to release patch versions for an old minor
> version. That is, 1.1.0 immediately supersedes 1.0.x, and no more fixes
> will be made on the 1.0.x line. Similarly, 1.2.0 immediately supersedes
> 1.1.x.
— http://wiki.apache.org/couchdb/CurrentReleases
I appreciate that this is the first time we've done this, so it might be a
little surprising to people. (Though, I believe, this has been the plan for
a good 12 months.) Let's closely monitor the situation, and if any issues
crop up, we deal with them.
On 21 May 2013 10:31, Jan Lehnardt <ja...@apache.org> wrote:
>
> On May 21, 2013, at 08:32 , Benoit Chesneau <bc...@gmail.com> wrote:
>
> > I thought we needed to support n and n-1. Did that change?
>
> It was my impression that that’s what we agreed on, as well.
>
> While 1.2.x -> 1.3.x is the recommended upgrade line, we pledged to
> do bugfixes and security issues for 1.2.x. Especially given that the
> view engine got a bit of a revamp, I could conceive of a situation
> where users wouldn’t want to make the jump to 1.3.x just yet.
>
> In a post 1.3.x strict-semver, we should have less of that, but for
> now I think it is wise to keep 1.2.x up (that said, we can resurrect
> the branch at any time, so we may as well leave it out until needed).
>
> Jan
> --
>
>
>
> >
> > - benoît
> > On May 21, 2013 3:43 AM, "Noah Slater" <ns...@apache.org> wrote:
> >
> >> Nope. 1.2.x is no longer an actively supported branch. 1.3.x is forwards
> >> compatible, and is the recommended upgrade path for anyone on 1.2.x.
> >>
> >>
> >> On 20 May 2013 20:56, Jan Lehnardt <ja...@apache.org> wrote:
> >>
> >>> Eh sorry, I just noticed that broke CI for 1.2.x which is surely still
> an
> >>> actively supported branch, shouldn’t we keep that around?
> >>>
> >>> Jan
> >>> --
> >>>
> >>> On May 18, 2013, at 22:24 , Jan Lehnardt <ja...@apache.org> wrote:
> >>>
> >>>>
> >>>>
> >>>> On 18.05.2013, at 19:56, Noah Slater <ns...@apache.org> wrote:
> >>>>
> >>>>> Based on the decision made in this thread, it would like to add
> >>> something
> >>>>> to the release procedure about deleting old branches when we drop
> >>> support
> >>>>> for that release line.
> >>>>>
> >>>>> As far as I understand it, no history is lost. The tags still point
> to
> >>> what
> >>>>> we shipped, and the commits still exist in the repository We're just
> >>>>> removing the pointers to the tips of the branches.
> >>>>>
> >>>>> Is this something I need to call another vote for, or am I free to
> add
> >>> it?
> >>>>
> >>>> Go for it.
> >>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 18 May 2013 18:50, Jan Lehnardt <ja...@apache.org> wrote:
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 18.05.2013, at 18:43, Noah Slater <ns...@apache.org> wrote:
> >>>>>>
> >>>>>>> Unfortunately, the deed is done. What is your reason for wanting to
> >>> keep
> >>>>>>> them around?
> >>>>>>
> >>>>>> History :)
> >>>>>>
> >>>>>> I have plenty of clones, so no worries :)
> >>>>>>
> >>>>>> Jan
> >>>>>> --
> >>>>>>
> >>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On 18 May 2013 18:38, Jan Lehnardt <ja...@apache.org> wrote:
> >>>>>>>
> >>>>>>>> Ah wow, that's what I get for going on vacation with unread
> >> threads.
> >>>>>>>>
> >>>>>>>> I'm major -1 on deleting old release branches, but I'd be happy to
> >>> have
> >>>>>>>> them moved to an archived repository. For the time being, I'll
> keep
> >>>>>> them on
> >>>>>>>> my GitHub.
> >>>>>>>>
> >>>>>>>> Cheers
> >>>>>>>> Jan
> >>>>>>>> --
> >>>>>>>>
> >>>>>>>> On 11.05.2013, at 17:31, Noah Slater <ns...@apache.org> wrote:
> >>>>>>>>
> >>>>>>>>> Thanks guys.
> >>>>>>>>>
> >>>>>>>>> All the Y.Y.x branches, with the exception of 1.3.x, have been
> >>> deleted.
> >>>>>>>>>
> >>>>>>>>> The following releases have been archived:
> >>>>>>>>>
> >>>>>>>>> * 1.0.4
> >>>>>>>>> * 1.1.2
> >>>>>>>>> * 1.2.1
> >>>>>>>>> * 1.2.2
> >>>>>>>>>
> >>>>>>>>> (Where archived means: removed from our wiki and dist dir.)
> >>>>>>>>>
> >>>>>>>>> I added the following to our CurrentReleases page:
> >>>>>>>>>
> >>>>>>>>> CouchDB uses [[http://semver.org/|semantic versioning]], so, in
> a
> >>>>>>>> nutshell:
> >>>>>>>>>
> >>>>>>>>> * X.Y.Z equates to major version, minor version, and bugfix
> >> version.
> >>>>>>>>> * The major version will be incremented every time we make
> >> backwards
> >>>>>>>>> incompatible changes.
> >>>>>>>>> * The minor version will be incremented every time we add
> >> backwards
> >>>>>>>>> compatible features.
> >>>>>>>>> * The patch version will be incremented every time we add
> >> backwards
> >>>>>>>>> compatible fixes.
> >>>>>>>>>
> >>>>>>>>> We will support each major version for 12 months. So, if 1.0.0
> was
> >>>>>>>> released
> >>>>>>>>> on 2010-01-01, then we would features and fixes to it until
> >>> 2011-01-01.
> >>>>>>>>> After 12 months have passed, we may continue to release fixes for
> >>>>>>>> critical
> >>>>>>>>> security issues, but these will be in the form of patches.
> >>>>>>>>>
> >>>>>>>>> Note that the upgrade path for minor versions is to update the
> >>> latest
> >>>>>>>> minor
> >>>>>>>>> version. We will not continue to release bugfix versions for an
> >> old
> >>>>>> minor
> >>>>>>>>> version. That is, 1.1.0 immediately supersedes 1.0.x, and no more
> >>> fixes
> >>>>>>>>> will be made on the 1.0.x line. Similarly, 1.2.0 immediately
> >>> supersedes
> >>>>>>>>> 1.1.x.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On 7 May 2013 19:34, Noah Slater <ns...@apache.org> wrote:
> >>>>>>>>>
> >>>>>>>>>> Devs,
> >>>>>>>>>>
> >>>>>>>>>> We're switching over to time-based releases.
> >>>>>>>>>>
> >>>>>>>>>> I took a moment to review our existing release branches today,
> >> and
> >>> I
> >>>>>>>> have
> >>>>>>>>>> prepared a list of recommendations for you. Please review these
> >> and
> >>>>>>>> give me
> >>>>>>>>>> feedback.
> >>>>>>>>>>
> >>>>>>>>>> By "drop support" I mean "make official" and while this is
> >>> ostensibly
> >>>>>>>> the
> >>>>>>>>>> case for a few of these, what I _really_ mean is "delete the
> >>> branch".
> >>>>>> I
> >>>>>>>> see
> >>>>>>>>>> no reason to keep this stuff around. It would make my life a lot
> >>>>>> easier
> >>>>>>>> if
> >>>>>>>>>> we could clean this stuff up.
> >>>>>>>>>>
> >>>>>>>>>> I'm not a Git expert, so I am relying on someone to sanity check
> >>> this.
> >>>>>>>>>> Remember: if we ever want to patch up a security issue in an
> >>>>>> unsupported
> >>>>>>>>>> release, we will be issuing a patch. So I am assuming what we'll
> >>> want
> >>>>>>>> to do
> >>>>>>>>>> is patch against the last tag for that release line. No need for
> >>> the
> >>>>>>>> branch
> >>>>>>>>>> at all as far as I can tell.
> >>>>>>>>>>
> >>>>>>>>>> If nobody objects in 72 hours, I will assume lazy consensus and
> >>>>>> proceed.
> >>>>>>>>>>
> >>>>>>>>>> ## 0.10.x line and before
> >>>>>>>>>>
> >>>>>>>>>> Really old stuff.
> >>>>>>>>>>
> >>>>>>>>>> Recommendation:
> >>>>>>>>>>
> >>>>>>>>>> * Drop support of these release lines
> >>>>>>>>>> * Delete the branches
> >>>>>>>>>>
> >>>>>>>>>> ## 0.11.x line
> >>>>>>>>>>
> >>>>>>>>>> First release: March 2010 (three years old)
> >>>>>>>>>>
> >>>>>>>>>> Unreleased changes:
> >>>>>>>>>>
> >>>>>>>>>> * Fix for frequently edited documents in multi-master
> deployments
> >>>>>> being
> >>>>>>>>>> duplicated in _changes and _all_docs.
> >>>>>>>>>>
> >>>>>>>>>> Recommendation:
> >>>>>>>>>>
> >>>>>>>>>> * Do not release these changes
> >>>>>>>>>> * Drop support of this release line
> >>>>>>>>>> * Delete the branch
> >>>>>>>>>>
> >>>>>>>>>> ## 1.0.x line
> >>>>>>>>>>
> >>>>>>>>>> First release: July 2010 (three years old)
> >>>>>>>>>>
> >>>>>>>>>> No unreleased changes.
> >>>>>>>>>>
> >>>>>>>>>> Recommendation:
> >>>>>>>>>>
> >>>>>>>>>> * Drop support of this release line
> >>>>>>>>>> * Delete the branch
> >>>>>>>>>>
> >>>>>>>>>> ## 1.1.x line
> >>>>>>>>>>
> >>>>>>>>>> First release: July 2011 (two years old)
> >>>>>>>>>>
> >>>>>>>>>> No unreleased changes.
> >>>>>>>>>>
> >>>>>>>>>> Recommendation:
> >>>>>>>>>>
> >>>>>>>>>> * Drop support of this release line
> >>>>>>>>>> * Delete the branch
> >>>>>>>>>>
> >>>>>>>>>> ## 1.2.x line
> >>>>>>>>>>
> >>>>>>>>>> First release: April 2012 (one year old)
> >>>>>>>>>>
> >>>>>>>>>> No unreleased changes.
> >>>>>>>>>>
> >>>>>>>>>> 1.3.x line is backwards compatible with 1.2.x.
> >>>>>>>>>>
> >>>>>>>>>> Recommendation:
> >>>>>>>>>>
> >>>>>>>>>> * Drop support of this release line
> >>>>>>>>>> * Delete the branch
> >>>>>>>>>>
> >>>>>>>>>> ## 1.3.x line
> >>>>>>>>>>
> >>>>>>>>>> First release: April 2013 (one month old)
> >>>>>>>>>>
> >>>>>>>>>> Unreleased changes:
> >>>>>>>>>>
> >>>>>>>>>> * Whatever bugfixes are on master or in branches right now.
> >>>>>>>>>>
> >>>>>>>>>> Recommendation:
> >>>>>>>>>>
> >>>>>>>>>> * Release 1.3.1 this month.
> >>>>>>>>>>
> >>>>>>>>>> Thanks,
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> NS
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> NS
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> NS
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> NS
> >>>
> >>>
> >>
> >>
> >> --
> >> NS
> >>
>
>
--
NS
Re: [DISCUSS] Release clean-up (delete ALL the branches!)
Posted by Jan Lehnardt <ja...@apache.org>.
On May 21, 2013, at 08:32 , Benoit Chesneau <bc...@gmail.com> wrote:
> I thought we needed to support n and n-1. Did that change?
It was my impression that that’s what we agreed on, as well.
While 1.2.x -> 1.3.x is the recommended upgrade line, we pledged to
do bugfixes and security issues for 1.2.x. Especially given that the
view engine got a bit of a revamp, I could conceive of a situation
where users wouldn’t want to make the jump to 1.3.x just yet.
In a post 1.3.x strict-semver, we should have less of that, but for
now I think it is wise to keep 1.2.x up (that said, we can resurrect
the branch at any time, so we may as well leave it out until needed).
Jan
--
>
> - benoît
> On May 21, 2013 3:43 AM, "Noah Slater" <ns...@apache.org> wrote:
>
>> Nope. 1.2.x is no longer an actively supported branch. 1.3.x is forwards
>> compatible, and is the recommended upgrade path for anyone on 1.2.x.
>>
>>
>> On 20 May 2013 20:56, Jan Lehnardt <ja...@apache.org> wrote:
>>
>>> Eh sorry, I just noticed that broke CI for 1.2.x which is surely still an
>>> actively supported branch, shouldn’t we keep that around?
>>>
>>> Jan
>>> --
>>>
>>> On May 18, 2013, at 22:24 , Jan Lehnardt <ja...@apache.org> wrote:
>>>
>>>>
>>>>
>>>> On 18.05.2013, at 19:56, Noah Slater <ns...@apache.org> wrote:
>>>>
>>>>> Based on the decision made in this thread, it would like to add
>>> something
>>>>> to the release procedure about deleting old branches when we drop
>>> support
>>>>> for that release line.
>>>>>
>>>>> As far as I understand it, no history is lost. The tags still point to
>>> what
>>>>> we shipped, and the commits still exist in the repository We're just
>>>>> removing the pointers to the tips of the branches.
>>>>>
>>>>> Is this something I need to call another vote for, or am I free to add
>>> it?
>>>>
>>>> Go for it.
>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 18 May 2013 18:50, Jan Lehnardt <ja...@apache.org> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On 18.05.2013, at 18:43, Noah Slater <ns...@apache.org> wrote:
>>>>>>
>>>>>>> Unfortunately, the deed is done. What is your reason for wanting to
>>> keep
>>>>>>> them around?
>>>>>>
>>>>>> History :)
>>>>>>
>>>>>> I have plenty of clones, so no worries :)
>>>>>>
>>>>>> Jan
>>>>>> --
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 18 May 2013 18:38, Jan Lehnardt <ja...@apache.org> wrote:
>>>>>>>
>>>>>>>> Ah wow, that's what I get for going on vacation with unread
>> threads.
>>>>>>>>
>>>>>>>> I'm major -1 on deleting old release branches, but I'd be happy to
>>> have
>>>>>>>> them moved to an archived repository. For the time being, I'll keep
>>>>>> them on
>>>>>>>> my GitHub.
>>>>>>>>
>>>>>>>> Cheers
>>>>>>>> Jan
>>>>>>>> --
>>>>>>>>
>>>>>>>> On 11.05.2013, at 17:31, Noah Slater <ns...@apache.org> wrote:
>>>>>>>>
>>>>>>>>> Thanks guys.
>>>>>>>>>
>>>>>>>>> All the Y.Y.x branches, with the exception of 1.3.x, have been
>>> deleted.
>>>>>>>>>
>>>>>>>>> The following releases have been archived:
>>>>>>>>>
>>>>>>>>> * 1.0.4
>>>>>>>>> * 1.1.2
>>>>>>>>> * 1.2.1
>>>>>>>>> * 1.2.2
>>>>>>>>>
>>>>>>>>> (Where archived means: removed from our wiki and dist dir.)
>>>>>>>>>
>>>>>>>>> I added the following to our CurrentReleases page:
>>>>>>>>>
>>>>>>>>> CouchDB uses [[http://semver.org/|semantic versioning]], so, in a
>>>>>>>> nutshell:
>>>>>>>>>
>>>>>>>>> * X.Y.Z equates to major version, minor version, and bugfix
>> version.
>>>>>>>>> * The major version will be incremented every time we make
>> backwards
>>>>>>>>> incompatible changes.
>>>>>>>>> * The minor version will be incremented every time we add
>> backwards
>>>>>>>>> compatible features.
>>>>>>>>> * The patch version will be incremented every time we add
>> backwards
>>>>>>>>> compatible fixes.
>>>>>>>>>
>>>>>>>>> We will support each major version for 12 months. So, if 1.0.0 was
>>>>>>>> released
>>>>>>>>> on 2010-01-01, then we would features and fixes to it until
>>> 2011-01-01.
>>>>>>>>> After 12 months have passed, we may continue to release fixes for
>>>>>>>> critical
>>>>>>>>> security issues, but these will be in the form of patches.
>>>>>>>>>
>>>>>>>>> Note that the upgrade path for minor versions is to update the
>>> latest
>>>>>>>> minor
>>>>>>>>> version. We will not continue to release bugfix versions for an
>> old
>>>>>> minor
>>>>>>>>> version. That is, 1.1.0 immediately supersedes 1.0.x, and no more
>>> fixes
>>>>>>>>> will be made on the 1.0.x line. Similarly, 1.2.0 immediately
>>> supersedes
>>>>>>>>> 1.1.x.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 7 May 2013 19:34, Noah Slater <ns...@apache.org> wrote:
>>>>>>>>>
>>>>>>>>>> Devs,
>>>>>>>>>>
>>>>>>>>>> We're switching over to time-based releases.
>>>>>>>>>>
>>>>>>>>>> I took a moment to review our existing release branches today,
>> and
>>> I
>>>>>>>> have
>>>>>>>>>> prepared a list of recommendations for you. Please review these
>> and
>>>>>>>> give me
>>>>>>>>>> feedback.
>>>>>>>>>>
>>>>>>>>>> By "drop support" I mean "make official" and while this is
>>> ostensibly
>>>>>>>> the
>>>>>>>>>> case for a few of these, what I _really_ mean is "delete the
>>> branch".
>>>>>> I
>>>>>>>> see
>>>>>>>>>> no reason to keep this stuff around. It would make my life a lot
>>>>>> easier
>>>>>>>> if
>>>>>>>>>> we could clean this stuff up.
>>>>>>>>>>
>>>>>>>>>> I'm not a Git expert, so I am relying on someone to sanity check
>>> this.
>>>>>>>>>> Remember: if we ever want to patch up a security issue in an
>>>>>> unsupported
>>>>>>>>>> release, we will be issuing a patch. So I am assuming what we'll
>>> want
>>>>>>>> to do
>>>>>>>>>> is patch against the last tag for that release line. No need for
>>> the
>>>>>>>> branch
>>>>>>>>>> at all as far as I can tell.
>>>>>>>>>>
>>>>>>>>>> If nobody objects in 72 hours, I will assume lazy consensus and
>>>>>> proceed.
>>>>>>>>>>
>>>>>>>>>> ## 0.10.x line and before
>>>>>>>>>>
>>>>>>>>>> Really old stuff.
>>>>>>>>>>
>>>>>>>>>> Recommendation:
>>>>>>>>>>
>>>>>>>>>> * Drop support of these release lines
>>>>>>>>>> * Delete the branches
>>>>>>>>>>
>>>>>>>>>> ## 0.11.x line
>>>>>>>>>>
>>>>>>>>>> First release: March 2010 (three years old)
>>>>>>>>>>
>>>>>>>>>> Unreleased changes:
>>>>>>>>>>
>>>>>>>>>> * Fix for frequently edited documents in multi-master deployments
>>>>>> being
>>>>>>>>>> duplicated in _changes and _all_docs.
>>>>>>>>>>
>>>>>>>>>> Recommendation:
>>>>>>>>>>
>>>>>>>>>> * Do not release these changes
>>>>>>>>>> * Drop support of this release line
>>>>>>>>>> * Delete the branch
>>>>>>>>>>
>>>>>>>>>> ## 1.0.x line
>>>>>>>>>>
>>>>>>>>>> First release: July 2010 (three years old)
>>>>>>>>>>
>>>>>>>>>> No unreleased changes.
>>>>>>>>>>
>>>>>>>>>> Recommendation:
>>>>>>>>>>
>>>>>>>>>> * Drop support of this release line
>>>>>>>>>> * Delete the branch
>>>>>>>>>>
>>>>>>>>>> ## 1.1.x line
>>>>>>>>>>
>>>>>>>>>> First release: July 2011 (two years old)
>>>>>>>>>>
>>>>>>>>>> No unreleased changes.
>>>>>>>>>>
>>>>>>>>>> Recommendation:
>>>>>>>>>>
>>>>>>>>>> * Drop support of this release line
>>>>>>>>>> * Delete the branch
>>>>>>>>>>
>>>>>>>>>> ## 1.2.x line
>>>>>>>>>>
>>>>>>>>>> First release: April 2012 (one year old)
>>>>>>>>>>
>>>>>>>>>> No unreleased changes.
>>>>>>>>>>
>>>>>>>>>> 1.3.x line is backwards compatible with 1.2.x.
>>>>>>>>>>
>>>>>>>>>> Recommendation:
>>>>>>>>>>
>>>>>>>>>> * Drop support of this release line
>>>>>>>>>> * Delete the branch
>>>>>>>>>>
>>>>>>>>>> ## 1.3.x line
>>>>>>>>>>
>>>>>>>>>> First release: April 2013 (one month old)
>>>>>>>>>>
>>>>>>>>>> Unreleased changes:
>>>>>>>>>>
>>>>>>>>>> * Whatever bugfixes are on master or in branches right now.
>>>>>>>>>>
>>>>>>>>>> Recommendation:
>>>>>>>>>>
>>>>>>>>>> * Release 1.3.1 this month.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> NS
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> NS
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> NS
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> NS
>>>
>>>
>>
>>
>> --
>> NS
>>
Re: [DISCUSS] Release clean-up (delete ALL the branches!)
Posted by Benoit Chesneau <bc...@gmail.com>.
I thought we needed to support n and n-1. Did that change?
- benoît
On May 21, 2013 3:43 AM, "Noah Slater" <ns...@apache.org> wrote:
> Nope. 1.2.x is no longer an actively supported branch. 1.3.x is forwards
> compatible, and is the recommended upgrade path for anyone on 1.2.x.
>
>
> On 20 May 2013 20:56, Jan Lehnardt <ja...@apache.org> wrote:
>
> > Eh sorry, I just noticed that broke CI for 1.2.x which is surely still an
> > actively supported branch, shouldn’t we keep that around?
> >
> > Jan
> > --
> >
> > On May 18, 2013, at 22:24 , Jan Lehnardt <ja...@apache.org> wrote:
> >
> > >
> > >
> > > On 18.05.2013, at 19:56, Noah Slater <ns...@apache.org> wrote:
> > >
> > >> Based on the decision made in this thread, it would like to add
> > something
> > >> to the release procedure about deleting old branches when we drop
> > support
> > >> for that release line.
> > >>
> > >> As far as I understand it, no history is lost. The tags still point to
> > what
> > >> we shipped, and the commits still exist in the repository We're just
> > >> removing the pointers to the tips of the branches.
> > >>
> > >> Is this something I need to call another vote for, or am I free to add
> > it?
> > >
> > > Go for it.
> > >
> > >>
> > >>
> > >>
> > >> On 18 May 2013 18:50, Jan Lehnardt <ja...@apache.org> wrote:
> > >>
> > >>>
> > >>>
> > >>> On 18.05.2013, at 18:43, Noah Slater <ns...@apache.org> wrote:
> > >>>
> > >>>> Unfortunately, the deed is done. What is your reason for wanting to
> > keep
> > >>>> them around?
> > >>>
> > >>> History :)
> > >>>
> > >>> I have plenty of clones, so no worries :)
> > >>>
> > >>> Jan
> > >>> --
> > >>>
> > >>>
> > >>>>
> > >>>>
> > >>>> On 18 May 2013 18:38, Jan Lehnardt <ja...@apache.org> wrote:
> > >>>>
> > >>>>> Ah wow, that's what I get for going on vacation with unread
> threads.
> > >>>>>
> > >>>>> I'm major -1 on deleting old release branches, but I'd be happy to
> > have
> > >>>>> them moved to an archived repository. For the time being, I'll keep
> > >>> them on
> > >>>>> my GitHub.
> > >>>>>
> > >>>>> Cheers
> > >>>>> Jan
> > >>>>> --
> > >>>>>
> > >>>>> On 11.05.2013, at 17:31, Noah Slater <ns...@apache.org> wrote:
> > >>>>>
> > >>>>>> Thanks guys.
> > >>>>>>
> > >>>>>> All the Y.Y.x branches, with the exception of 1.3.x, have been
> > deleted.
> > >>>>>>
> > >>>>>> The following releases have been archived:
> > >>>>>>
> > >>>>>> * 1.0.4
> > >>>>>> * 1.1.2
> > >>>>>> * 1.2.1
> > >>>>>> * 1.2.2
> > >>>>>>
> > >>>>>> (Where archived means: removed from our wiki and dist dir.)
> > >>>>>>
> > >>>>>> I added the following to our CurrentReleases page:
> > >>>>>>
> > >>>>>> CouchDB uses [[http://semver.org/|semantic versioning]], so, in a
> > >>>>> nutshell:
> > >>>>>>
> > >>>>>> * X.Y.Z equates to major version, minor version, and bugfix
> version.
> > >>>>>> * The major version will be incremented every time we make
> backwards
> > >>>>>> incompatible changes.
> > >>>>>> * The minor version will be incremented every time we add
> backwards
> > >>>>>> compatible features.
> > >>>>>> * The patch version will be incremented every time we add
> backwards
> > >>>>>> compatible fixes.
> > >>>>>>
> > >>>>>> We will support each major version for 12 months. So, if 1.0.0 was
> > >>>>> released
> > >>>>>> on 2010-01-01, then we would features and fixes to it until
> > 2011-01-01.
> > >>>>>> After 12 months have passed, we may continue to release fixes for
> > >>>>> critical
> > >>>>>> security issues, but these will be in the form of patches.
> > >>>>>>
> > >>>>>> Note that the upgrade path for minor versions is to update the
> > latest
> > >>>>> minor
> > >>>>>> version. We will not continue to release bugfix versions for an
> old
> > >>> minor
> > >>>>>> version. That is, 1.1.0 immediately supersedes 1.0.x, and no more
> > fixes
> > >>>>>> will be made on the 1.0.x line. Similarly, 1.2.0 immediately
> > supersedes
> > >>>>>> 1.1.x.
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> On 7 May 2013 19:34, Noah Slater <ns...@apache.org> wrote:
> > >>>>>>
> > >>>>>>> Devs,
> > >>>>>>>
> > >>>>>>> We're switching over to time-based releases.
> > >>>>>>>
> > >>>>>>> I took a moment to review our existing release branches today,
> and
> > I
> > >>>>> have
> > >>>>>>> prepared a list of recommendations for you. Please review these
> and
> > >>>>> give me
> > >>>>>>> feedback.
> > >>>>>>>
> > >>>>>>> By "drop support" I mean "make official" and while this is
> > ostensibly
> > >>>>> the
> > >>>>>>> case for a few of these, what I _really_ mean is "delete the
> > branch".
> > >>> I
> > >>>>> see
> > >>>>>>> no reason to keep this stuff around. It would make my life a lot
> > >>> easier
> > >>>>> if
> > >>>>>>> we could clean this stuff up.
> > >>>>>>>
> > >>>>>>> I'm not a Git expert, so I am relying on someone to sanity check
> > this.
> > >>>>>>> Remember: if we ever want to patch up a security issue in an
> > >>> unsupported
> > >>>>>>> release, we will be issuing a patch. So I am assuming what we'll
> > want
> > >>>>> to do
> > >>>>>>> is patch against the last tag for that release line. No need for
> > the
> > >>>>> branch
> > >>>>>>> at all as far as I can tell.
> > >>>>>>>
> > >>>>>>> If nobody objects in 72 hours, I will assume lazy consensus and
> > >>> proceed.
> > >>>>>>>
> > >>>>>>> ## 0.10.x line and before
> > >>>>>>>
> > >>>>>>> Really old stuff.
> > >>>>>>>
> > >>>>>>> Recommendation:
> > >>>>>>>
> > >>>>>>> * Drop support of these release lines
> > >>>>>>> * Delete the branches
> > >>>>>>>
> > >>>>>>> ## 0.11.x line
> > >>>>>>>
> > >>>>>>> First release: March 2010 (three years old)
> > >>>>>>>
> > >>>>>>> Unreleased changes:
> > >>>>>>>
> > >>>>>>> * Fix for frequently edited documents in multi-master deployments
> > >>> being
> > >>>>>>> duplicated in _changes and _all_docs.
> > >>>>>>>
> > >>>>>>> Recommendation:
> > >>>>>>>
> > >>>>>>> * Do not release these changes
> > >>>>>>> * Drop support of this release line
> > >>>>>>> * Delete the branch
> > >>>>>>>
> > >>>>>>> ## 1.0.x line
> > >>>>>>>
> > >>>>>>> First release: July 2010 (three years old)
> > >>>>>>>
> > >>>>>>> No unreleased changes.
> > >>>>>>>
> > >>>>>>> Recommendation:
> > >>>>>>>
> > >>>>>>> * Drop support of this release line
> > >>>>>>> * Delete the branch
> > >>>>>>>
> > >>>>>>> ## 1.1.x line
> > >>>>>>>
> > >>>>>>> First release: July 2011 (two years old)
> > >>>>>>>
> > >>>>>>> No unreleased changes.
> > >>>>>>>
> > >>>>>>> Recommendation:
> > >>>>>>>
> > >>>>>>> * Drop support of this release line
> > >>>>>>> * Delete the branch
> > >>>>>>>
> > >>>>>>> ## 1.2.x line
> > >>>>>>>
> > >>>>>>> First release: April 2012 (one year old)
> > >>>>>>>
> > >>>>>>> No unreleased changes.
> > >>>>>>>
> > >>>>>>> 1.3.x line is backwards compatible with 1.2.x.
> > >>>>>>>
> > >>>>>>> Recommendation:
> > >>>>>>>
> > >>>>>>> * Drop support of this release line
> > >>>>>>> * Delete the branch
> > >>>>>>>
> > >>>>>>> ## 1.3.x line
> > >>>>>>>
> > >>>>>>> First release: April 2013 (one month old)
> > >>>>>>>
> > >>>>>>> Unreleased changes:
> > >>>>>>>
> > >>>>>>> * Whatever bugfixes are on master or in branches right now.
> > >>>>>>>
> > >>>>>>> Recommendation:
> > >>>>>>>
> > >>>>>>> * Release 1.3.1 this month.
> > >>>>>>>
> > >>>>>>> Thanks,
> > >>>>>>>
> > >>>>>>> --
> > >>>>>>> NS
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> --
> > >>>>>> NS
> > >>>>
> > >>>>
> > >>>>
> > >>>> --
> > >>>> NS
> > >>>
> > >>
> > >>
> > >>
> > >> --
> > >> NS
> >
> >
>
>
> --
> NS
>
Re: [DISCUSS] Release clean-up (delete ALL the branches!)
Posted by Noah Slater <ns...@apache.org>.
Nope. 1.2.x is no longer an actively supported branch. 1.3.x is forwards
compatible, and is the recommended upgrade path for anyone on 1.2.x.
On 20 May 2013 20:56, Jan Lehnardt <ja...@apache.org> wrote:
> Eh sorry, I just noticed that broke CI for 1.2.x which is surely still an
> actively supported branch, shouldn’t we keep that around?
>
> Jan
> --
>
> On May 18, 2013, at 22:24 , Jan Lehnardt <ja...@apache.org> wrote:
>
> >
> >
> > On 18.05.2013, at 19:56, Noah Slater <ns...@apache.org> wrote:
> >
> >> Based on the decision made in this thread, it would like to add
> something
> >> to the release procedure about deleting old branches when we drop
> support
> >> for that release line.
> >>
> >> As far as I understand it, no history is lost. The tags still point to
> what
> >> we shipped, and the commits still exist in the repository We're just
> >> removing the pointers to the tips of the branches.
> >>
> >> Is this something I need to call another vote for, or am I free to add
> it?
> >
> > Go for it.
> >
> >>
> >>
> >>
> >> On 18 May 2013 18:50, Jan Lehnardt <ja...@apache.org> wrote:
> >>
> >>>
> >>>
> >>> On 18.05.2013, at 18:43, Noah Slater <ns...@apache.org> wrote:
> >>>
> >>>> Unfortunately, the deed is done. What is your reason for wanting to
> keep
> >>>> them around?
> >>>
> >>> History :)
> >>>
> >>> I have plenty of clones, so no worries :)
> >>>
> >>> Jan
> >>> --
> >>>
> >>>
> >>>>
> >>>>
> >>>> On 18 May 2013 18:38, Jan Lehnardt <ja...@apache.org> wrote:
> >>>>
> >>>>> Ah wow, that's what I get for going on vacation with unread threads.
> >>>>>
> >>>>> I'm major -1 on deleting old release branches, but I'd be happy to
> have
> >>>>> them moved to an archived repository. For the time being, I'll keep
> >>> them on
> >>>>> my GitHub.
> >>>>>
> >>>>> Cheers
> >>>>> Jan
> >>>>> --
> >>>>>
> >>>>> On 11.05.2013, at 17:31, Noah Slater <ns...@apache.org> wrote:
> >>>>>
> >>>>>> Thanks guys.
> >>>>>>
> >>>>>> All the Y.Y.x branches, with the exception of 1.3.x, have been
> deleted.
> >>>>>>
> >>>>>> The following releases have been archived:
> >>>>>>
> >>>>>> * 1.0.4
> >>>>>> * 1.1.2
> >>>>>> * 1.2.1
> >>>>>> * 1.2.2
> >>>>>>
> >>>>>> (Where archived means: removed from our wiki and dist dir.)
> >>>>>>
> >>>>>> I added the following to our CurrentReleases page:
> >>>>>>
> >>>>>> CouchDB uses [[http://semver.org/|semantic versioning]], so, in a
> >>>>> nutshell:
> >>>>>>
> >>>>>> * X.Y.Z equates to major version, minor version, and bugfix version.
> >>>>>> * The major version will be incremented every time we make backwards
> >>>>>> incompatible changes.
> >>>>>> * The minor version will be incremented every time we add backwards
> >>>>>> compatible features.
> >>>>>> * The patch version will be incremented every time we add backwards
> >>>>>> compatible fixes.
> >>>>>>
> >>>>>> We will support each major version for 12 months. So, if 1.0.0 was
> >>>>> released
> >>>>>> on 2010-01-01, then we would features and fixes to it until
> 2011-01-01.
> >>>>>> After 12 months have passed, we may continue to release fixes for
> >>>>> critical
> >>>>>> security issues, but these will be in the form of patches.
> >>>>>>
> >>>>>> Note that the upgrade path for minor versions is to update the
> latest
> >>>>> minor
> >>>>>> version. We will not continue to release bugfix versions for an old
> >>> minor
> >>>>>> version. That is, 1.1.0 immediately supersedes 1.0.x, and no more
> fixes
> >>>>>> will be made on the 1.0.x line. Similarly, 1.2.0 immediately
> supersedes
> >>>>>> 1.1.x.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 7 May 2013 19:34, Noah Slater <ns...@apache.org> wrote:
> >>>>>>
> >>>>>>> Devs,
> >>>>>>>
> >>>>>>> We're switching over to time-based releases.
> >>>>>>>
> >>>>>>> I took a moment to review our existing release branches today, and
> I
> >>>>> have
> >>>>>>> prepared a list of recommendations for you. Please review these and
> >>>>> give me
> >>>>>>> feedback.
> >>>>>>>
> >>>>>>> By "drop support" I mean "make official" and while this is
> ostensibly
> >>>>> the
> >>>>>>> case for a few of these, what I _really_ mean is "delete the
> branch".
> >>> I
> >>>>> see
> >>>>>>> no reason to keep this stuff around. It would make my life a lot
> >>> easier
> >>>>> if
> >>>>>>> we could clean this stuff up.
> >>>>>>>
> >>>>>>> I'm not a Git expert, so I am relying on someone to sanity check
> this.
> >>>>>>> Remember: if we ever want to patch up a security issue in an
> >>> unsupported
> >>>>>>> release, we will be issuing a patch. So I am assuming what we'll
> want
> >>>>> to do
> >>>>>>> is patch against the last tag for that release line. No need for
> the
> >>>>> branch
> >>>>>>> at all as far as I can tell.
> >>>>>>>
> >>>>>>> If nobody objects in 72 hours, I will assume lazy consensus and
> >>> proceed.
> >>>>>>>
> >>>>>>> ## 0.10.x line and before
> >>>>>>>
> >>>>>>> Really old stuff.
> >>>>>>>
> >>>>>>> Recommendation:
> >>>>>>>
> >>>>>>> * Drop support of these release lines
> >>>>>>> * Delete the branches
> >>>>>>>
> >>>>>>> ## 0.11.x line
> >>>>>>>
> >>>>>>> First release: March 2010 (three years old)
> >>>>>>>
> >>>>>>> Unreleased changes:
> >>>>>>>
> >>>>>>> * Fix for frequently edited documents in multi-master deployments
> >>> being
> >>>>>>> duplicated in _changes and _all_docs.
> >>>>>>>
> >>>>>>> Recommendation:
> >>>>>>>
> >>>>>>> * Do not release these changes
> >>>>>>> * Drop support of this release line
> >>>>>>> * Delete the branch
> >>>>>>>
> >>>>>>> ## 1.0.x line
> >>>>>>>
> >>>>>>> First release: July 2010 (three years old)
> >>>>>>>
> >>>>>>> No unreleased changes.
> >>>>>>>
> >>>>>>> Recommendation:
> >>>>>>>
> >>>>>>> * Drop support of this release line
> >>>>>>> * Delete the branch
> >>>>>>>
> >>>>>>> ## 1.1.x line
> >>>>>>>
> >>>>>>> First release: July 2011 (two years old)
> >>>>>>>
> >>>>>>> No unreleased changes.
> >>>>>>>
> >>>>>>> Recommendation:
> >>>>>>>
> >>>>>>> * Drop support of this release line
> >>>>>>> * Delete the branch
> >>>>>>>
> >>>>>>> ## 1.2.x line
> >>>>>>>
> >>>>>>> First release: April 2012 (one year old)
> >>>>>>>
> >>>>>>> No unreleased changes.
> >>>>>>>
> >>>>>>> 1.3.x line is backwards compatible with 1.2.x.
> >>>>>>>
> >>>>>>> Recommendation:
> >>>>>>>
> >>>>>>> * Drop support of this release line
> >>>>>>> * Delete the branch
> >>>>>>>
> >>>>>>> ## 1.3.x line
> >>>>>>>
> >>>>>>> First release: April 2013 (one month old)
> >>>>>>>
> >>>>>>> Unreleased changes:
> >>>>>>>
> >>>>>>> * Whatever bugfixes are on master or in branches right now.
> >>>>>>>
> >>>>>>> Recommendation:
> >>>>>>>
> >>>>>>> * Release 1.3.1 this month.
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>>
> >>>>>>> --
> >>>>>>> NS
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> NS
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> NS
> >>>
> >>
> >>
> >>
> >> --
> >> NS
>
>
--
NS
Re: [DISCUSS] Release clean-up (delete ALL the branches!)
Posted by Jan Lehnardt <ja...@apache.org>.
Eh sorry, I just noticed that broke CI for 1.2.x which is surely still an
actively supported branch, shouldn’t we keep that around?
Jan
--
On May 18, 2013, at 22:24 , Jan Lehnardt <ja...@apache.org> wrote:
>
>
> On 18.05.2013, at 19:56, Noah Slater <ns...@apache.org> wrote:
>
>> Based on the decision made in this thread, it would like to add something
>> to the release procedure about deleting old branches when we drop support
>> for that release line.
>>
>> As far as I understand it, no history is lost. The tags still point to what
>> we shipped, and the commits still exist in the repository We're just
>> removing the pointers to the tips of the branches.
>>
>> Is this something I need to call another vote for, or am I free to add it?
>
> Go for it.
>
>>
>>
>>
>> On 18 May 2013 18:50, Jan Lehnardt <ja...@apache.org> wrote:
>>
>>>
>>>
>>> On 18.05.2013, at 18:43, Noah Slater <ns...@apache.org> wrote:
>>>
>>>> Unfortunately, the deed is done. What is your reason for wanting to keep
>>>> them around?
>>>
>>> History :)
>>>
>>> I have plenty of clones, so no worries :)
>>>
>>> Jan
>>> --
>>>
>>>
>>>>
>>>>
>>>> On 18 May 2013 18:38, Jan Lehnardt <ja...@apache.org> wrote:
>>>>
>>>>> Ah wow, that's what I get for going on vacation with unread threads.
>>>>>
>>>>> I'm major -1 on deleting old release branches, but I'd be happy to have
>>>>> them moved to an archived repository. For the time being, I'll keep
>>> them on
>>>>> my GitHub.
>>>>>
>>>>> Cheers
>>>>> Jan
>>>>> --
>>>>>
>>>>> On 11.05.2013, at 17:31, Noah Slater <ns...@apache.org> wrote:
>>>>>
>>>>>> Thanks guys.
>>>>>>
>>>>>> All the Y.Y.x branches, with the exception of 1.3.x, have been deleted.
>>>>>>
>>>>>> The following releases have been archived:
>>>>>>
>>>>>> * 1.0.4
>>>>>> * 1.1.2
>>>>>> * 1.2.1
>>>>>> * 1.2.2
>>>>>>
>>>>>> (Where archived means: removed from our wiki and dist dir.)
>>>>>>
>>>>>> I added the following to our CurrentReleases page:
>>>>>>
>>>>>> CouchDB uses [[http://semver.org/|semantic versioning]], so, in a
>>>>> nutshell:
>>>>>>
>>>>>> * X.Y.Z equates to major version, minor version, and bugfix version.
>>>>>> * The major version will be incremented every time we make backwards
>>>>>> incompatible changes.
>>>>>> * The minor version will be incremented every time we add backwards
>>>>>> compatible features.
>>>>>> * The patch version will be incremented every time we add backwards
>>>>>> compatible fixes.
>>>>>>
>>>>>> We will support each major version for 12 months. So, if 1.0.0 was
>>>>> released
>>>>>> on 2010-01-01, then we would features and fixes to it until 2011-01-01.
>>>>>> After 12 months have passed, we may continue to release fixes for
>>>>> critical
>>>>>> security issues, but these will be in the form of patches.
>>>>>>
>>>>>> Note that the upgrade path for minor versions is to update the latest
>>>>> minor
>>>>>> version. We will not continue to release bugfix versions for an old
>>> minor
>>>>>> version. That is, 1.1.0 immediately supersedes 1.0.x, and no more fixes
>>>>>> will be made on the 1.0.x line. Similarly, 1.2.0 immediately supersedes
>>>>>> 1.1.x.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 7 May 2013 19:34, Noah Slater <ns...@apache.org> wrote:
>>>>>>
>>>>>>> Devs,
>>>>>>>
>>>>>>> We're switching over to time-based releases.
>>>>>>>
>>>>>>> I took a moment to review our existing release branches today, and I
>>>>> have
>>>>>>> prepared a list of recommendations for you. Please review these and
>>>>> give me
>>>>>>> feedback.
>>>>>>>
>>>>>>> By "drop support" I mean "make official" and while this is ostensibly
>>>>> the
>>>>>>> case for a few of these, what I _really_ mean is "delete the branch".
>>> I
>>>>> see
>>>>>>> no reason to keep this stuff around. It would make my life a lot
>>> easier
>>>>> if
>>>>>>> we could clean this stuff up.
>>>>>>>
>>>>>>> I'm not a Git expert, so I am relying on someone to sanity check this.
>>>>>>> Remember: if we ever want to patch up a security issue in an
>>> unsupported
>>>>>>> release, we will be issuing a patch. So I am assuming what we'll want
>>>>> to do
>>>>>>> is patch against the last tag for that release line. No need for the
>>>>> branch
>>>>>>> at all as far as I can tell.
>>>>>>>
>>>>>>> If nobody objects in 72 hours, I will assume lazy consensus and
>>> proceed.
>>>>>>>
>>>>>>> ## 0.10.x line and before
>>>>>>>
>>>>>>> Really old stuff.
>>>>>>>
>>>>>>> Recommendation:
>>>>>>>
>>>>>>> * Drop support of these release lines
>>>>>>> * Delete the branches
>>>>>>>
>>>>>>> ## 0.11.x line
>>>>>>>
>>>>>>> First release: March 2010 (three years old)
>>>>>>>
>>>>>>> Unreleased changes:
>>>>>>>
>>>>>>> * Fix for frequently edited documents in multi-master deployments
>>> being
>>>>>>> duplicated in _changes and _all_docs.
>>>>>>>
>>>>>>> Recommendation:
>>>>>>>
>>>>>>> * Do not release these changes
>>>>>>> * Drop support of this release line
>>>>>>> * Delete the branch
>>>>>>>
>>>>>>> ## 1.0.x line
>>>>>>>
>>>>>>> First release: July 2010 (three years old)
>>>>>>>
>>>>>>> No unreleased changes.
>>>>>>>
>>>>>>> Recommendation:
>>>>>>>
>>>>>>> * Drop support of this release line
>>>>>>> * Delete the branch
>>>>>>>
>>>>>>> ## 1.1.x line
>>>>>>>
>>>>>>> First release: July 2011 (two years old)
>>>>>>>
>>>>>>> No unreleased changes.
>>>>>>>
>>>>>>> Recommendation:
>>>>>>>
>>>>>>> * Drop support of this release line
>>>>>>> * Delete the branch
>>>>>>>
>>>>>>> ## 1.2.x line
>>>>>>>
>>>>>>> First release: April 2012 (one year old)
>>>>>>>
>>>>>>> No unreleased changes.
>>>>>>>
>>>>>>> 1.3.x line is backwards compatible with 1.2.x.
>>>>>>>
>>>>>>> Recommendation:
>>>>>>>
>>>>>>> * Drop support of this release line
>>>>>>> * Delete the branch
>>>>>>>
>>>>>>> ## 1.3.x line
>>>>>>>
>>>>>>> First release: April 2013 (one month old)
>>>>>>>
>>>>>>> Unreleased changes:
>>>>>>>
>>>>>>> * Whatever bugfixes are on master or in branches right now.
>>>>>>>
>>>>>>> Recommendation:
>>>>>>>
>>>>>>> * Release 1.3.1 this month.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> --
>>>>>>> NS
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> NS
>>>>
>>>>
>>>>
>>>> --
>>>> NS
>>>
>>
>>
>>
>> --
>> NS
Re: [DISCUSS] Release clean-up (delete ALL the branches!)
Posted by Jan Lehnardt <ja...@apache.org>.
On 18.05.2013, at 19:56, Noah Slater <ns...@apache.org> wrote:
> Based on the decision made in this thread, it would like to add something
> to the release procedure about deleting old branches when we drop support
> for that release line.
>
> As far as I understand it, no history is lost. The tags still point to what
> we shipped, and the commits still exist in the repository We're just
> removing the pointers to the tips of the branches.
>
> Is this something I need to call another vote for, or am I free to add it?
Go for it.
>
>
>
> On 18 May 2013 18:50, Jan Lehnardt <ja...@apache.org> wrote:
>
>>
>>
>> On 18.05.2013, at 18:43, Noah Slater <ns...@apache.org> wrote:
>>
>>> Unfortunately, the deed is done. What is your reason for wanting to keep
>>> them around?
>>
>> History :)
>>
>> I have plenty of clones, so no worries :)
>>
>> Jan
>> --
>>
>>
>>>
>>>
>>> On 18 May 2013 18:38, Jan Lehnardt <ja...@apache.org> wrote:
>>>
>>>> Ah wow, that's what I get for going on vacation with unread threads.
>>>>
>>>> I'm major -1 on deleting old release branches, but I'd be happy to have
>>>> them moved to an archived repository. For the time being, I'll keep
>> them on
>>>> my GitHub.
>>>>
>>>> Cheers
>>>> Jan
>>>> --
>>>>
>>>> On 11.05.2013, at 17:31, Noah Slater <ns...@apache.org> wrote:
>>>>
>>>>> Thanks guys.
>>>>>
>>>>> All the Y.Y.x branches, with the exception of 1.3.x, have been deleted.
>>>>>
>>>>> The following releases have been archived:
>>>>>
>>>>> * 1.0.4
>>>>> * 1.1.2
>>>>> * 1.2.1
>>>>> * 1.2.2
>>>>>
>>>>> (Where archived means: removed from our wiki and dist dir.)
>>>>>
>>>>> I added the following to our CurrentReleases page:
>>>>>
>>>>> CouchDB uses [[http://semver.org/|semantic versioning]], so, in a
>>>> nutshell:
>>>>>
>>>>> * X.Y.Z equates to major version, minor version, and bugfix version.
>>>>> * The major version will be incremented every time we make backwards
>>>>> incompatible changes.
>>>>> * The minor version will be incremented every time we add backwards
>>>>> compatible features.
>>>>> * The patch version will be incremented every time we add backwards
>>>>> compatible fixes.
>>>>>
>>>>> We will support each major version for 12 months. So, if 1.0.0 was
>>>> released
>>>>> on 2010-01-01, then we would features and fixes to it until 2011-01-01.
>>>>> After 12 months have passed, we may continue to release fixes for
>>>> critical
>>>>> security issues, but these will be in the form of patches.
>>>>>
>>>>> Note that the upgrade path for minor versions is to update the latest
>>>> minor
>>>>> version. We will not continue to release bugfix versions for an old
>> minor
>>>>> version. That is, 1.1.0 immediately supersedes 1.0.x, and no more fixes
>>>>> will be made on the 1.0.x line. Similarly, 1.2.0 immediately supersedes
>>>>> 1.1.x.
>>>>>
>>>>>
>>>>>
>>>>> On 7 May 2013 19:34, Noah Slater <ns...@apache.org> wrote:
>>>>>
>>>>>> Devs,
>>>>>>
>>>>>> We're switching over to time-based releases.
>>>>>>
>>>>>> I took a moment to review our existing release branches today, and I
>>>> have
>>>>>> prepared a list of recommendations for you. Please review these and
>>>> give me
>>>>>> feedback.
>>>>>>
>>>>>> By "drop support" I mean "make official" and while this is ostensibly
>>>> the
>>>>>> case for a few of these, what I _really_ mean is "delete the branch".
>> I
>>>> see
>>>>>> no reason to keep this stuff around. It would make my life a lot
>> easier
>>>> if
>>>>>> we could clean this stuff up.
>>>>>>
>>>>>> I'm not a Git expert, so I am relying on someone to sanity check this.
>>>>>> Remember: if we ever want to patch up a security issue in an
>> unsupported
>>>>>> release, we will be issuing a patch. So I am assuming what we'll want
>>>> to do
>>>>>> is patch against the last tag for that release line. No need for the
>>>> branch
>>>>>> at all as far as I can tell.
>>>>>>
>>>>>> If nobody objects in 72 hours, I will assume lazy consensus and
>> proceed.
>>>>>>
>>>>>> ## 0.10.x line and before
>>>>>>
>>>>>> Really old stuff.
>>>>>>
>>>>>> Recommendation:
>>>>>>
>>>>>> * Drop support of these release lines
>>>>>> * Delete the branches
>>>>>>
>>>>>> ## 0.11.x line
>>>>>>
>>>>>> First release: March 2010 (three years old)
>>>>>>
>>>>>> Unreleased changes:
>>>>>>
>>>>>> * Fix for frequently edited documents in multi-master deployments
>> being
>>>>>> duplicated in _changes and _all_docs.
>>>>>>
>>>>>> Recommendation:
>>>>>>
>>>>>> * Do not release these changes
>>>>>> * Drop support of this release line
>>>>>> * Delete the branch
>>>>>>
>>>>>> ## 1.0.x line
>>>>>>
>>>>>> First release: July 2010 (three years old)
>>>>>>
>>>>>> No unreleased changes.
>>>>>>
>>>>>> Recommendation:
>>>>>>
>>>>>> * Drop support of this release line
>>>>>> * Delete the branch
>>>>>>
>>>>>> ## 1.1.x line
>>>>>>
>>>>>> First release: July 2011 (two years old)
>>>>>>
>>>>>> No unreleased changes.
>>>>>>
>>>>>> Recommendation:
>>>>>>
>>>>>> * Drop support of this release line
>>>>>> * Delete the branch
>>>>>>
>>>>>> ## 1.2.x line
>>>>>>
>>>>>> First release: April 2012 (one year old)
>>>>>>
>>>>>> No unreleased changes.
>>>>>>
>>>>>> 1.3.x line is backwards compatible with 1.2.x.
>>>>>>
>>>>>> Recommendation:
>>>>>>
>>>>>> * Drop support of this release line
>>>>>> * Delete the branch
>>>>>>
>>>>>> ## 1.3.x line
>>>>>>
>>>>>> First release: April 2013 (one month old)
>>>>>>
>>>>>> Unreleased changes:
>>>>>>
>>>>>> * Whatever bugfixes are on master or in branches right now.
>>>>>>
>>>>>> Recommendation:
>>>>>>
>>>>>> * Release 1.3.1 this month.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> --
>>>>>> NS
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> NS
>>>
>>>
>>>
>>> --
>>> NS
>>
>
>
>
> --
> NS
Re: [DISCUSS] Release clean-up (delete ALL the branches!)
Posted by Noah Slater <ns...@apache.org>.
Based on the decision made in this thread, it would like to add something
to the release procedure about deleting old branches when we drop support
for that release line.
As far as I understand it, no history is lost. The tags still point to what
we shipped, and the commits still exist in the repository We're just
removing the pointers to the tips of the branches.
Is this something I need to call another vote for, or am I free to add it?
On 18 May 2013 18:50, Jan Lehnardt <ja...@apache.org> wrote:
>
>
> On 18.05.2013, at 18:43, Noah Slater <ns...@apache.org> wrote:
>
> > Unfortunately, the deed is done. What is your reason for wanting to keep
> > them around?
>
> History :)
>
> I have plenty of clones, so no worries :)
>
> Jan
> --
>
>
> >
> >
> > On 18 May 2013 18:38, Jan Lehnardt <ja...@apache.org> wrote:
> >
> >> Ah wow, that's what I get for going on vacation with unread threads.
> >>
> >> I'm major -1 on deleting old release branches, but I'd be happy to have
> >> them moved to an archived repository. For the time being, I'll keep
> them on
> >> my GitHub.
> >>
> >> Cheers
> >> Jan
> >> --
> >>
> >> On 11.05.2013, at 17:31, Noah Slater <ns...@apache.org> wrote:
> >>
> >>> Thanks guys.
> >>>
> >>> All the Y.Y.x branches, with the exception of 1.3.x, have been deleted.
> >>>
> >>> The following releases have been archived:
> >>>
> >>> * 1.0.4
> >>> * 1.1.2
> >>> * 1.2.1
> >>> * 1.2.2
> >>>
> >>> (Where archived means: removed from our wiki and dist dir.)
> >>>
> >>> I added the following to our CurrentReleases page:
> >>>
> >>> CouchDB uses [[http://semver.org/|semantic versioning]], so, in a
> >> nutshell:
> >>>
> >>> * X.Y.Z equates to major version, minor version, and bugfix version.
> >>> * The major version will be incremented every time we make backwards
> >>> incompatible changes.
> >>> * The minor version will be incremented every time we add backwards
> >>> compatible features.
> >>> * The patch version will be incremented every time we add backwards
> >>> compatible fixes.
> >>>
> >>> We will support each major version for 12 months. So, if 1.0.0 was
> >> released
> >>> on 2010-01-01, then we would features and fixes to it until 2011-01-01.
> >>> After 12 months have passed, we may continue to release fixes for
> >> critical
> >>> security issues, but these will be in the form of patches.
> >>>
> >>> Note that the upgrade path for minor versions is to update the latest
> >> minor
> >>> version. We will not continue to release bugfix versions for an old
> minor
> >>> version. That is, 1.1.0 immediately supersedes 1.0.x, and no more fixes
> >>> will be made on the 1.0.x line. Similarly, 1.2.0 immediately supersedes
> >>> 1.1.x.
> >>>
> >>>
> >>>
> >>> On 7 May 2013 19:34, Noah Slater <ns...@apache.org> wrote:
> >>>
> >>>> Devs,
> >>>>
> >>>> We're switching over to time-based releases.
> >>>>
> >>>> I took a moment to review our existing release branches today, and I
> >> have
> >>>> prepared a list of recommendations for you. Please review these and
> >> give me
> >>>> feedback.
> >>>>
> >>>> By "drop support" I mean "make official" and while this is ostensibly
> >> the
> >>>> case for a few of these, what I _really_ mean is "delete the branch".
> I
> >> see
> >>>> no reason to keep this stuff around. It would make my life a lot
> easier
> >> if
> >>>> we could clean this stuff up.
> >>>>
> >>>> I'm not a Git expert, so I am relying on someone to sanity check this.
> >>>> Remember: if we ever want to patch up a security issue in an
> unsupported
> >>>> release, we will be issuing a patch. So I am assuming what we'll want
> >> to do
> >>>> is patch against the last tag for that release line. No need for the
> >> branch
> >>>> at all as far as I can tell.
> >>>>
> >>>> If nobody objects in 72 hours, I will assume lazy consensus and
> proceed.
> >>>>
> >>>> ## 0.10.x line and before
> >>>>
> >>>> Really old stuff.
> >>>>
> >>>> Recommendation:
> >>>>
> >>>> * Drop support of these release lines
> >>>> * Delete the branches
> >>>>
> >>>> ## 0.11.x line
> >>>>
> >>>> First release: March 2010 (three years old)
> >>>>
> >>>> Unreleased changes:
> >>>>
> >>>> * Fix for frequently edited documents in multi-master deployments
> being
> >>>> duplicated in _changes and _all_docs.
> >>>>
> >>>> Recommendation:
> >>>>
> >>>> * Do not release these changes
> >>>> * Drop support of this release line
> >>>> * Delete the branch
> >>>>
> >>>> ## 1.0.x line
> >>>>
> >>>> First release: July 2010 (three years old)
> >>>>
> >>>> No unreleased changes.
> >>>>
> >>>> Recommendation:
> >>>>
> >>>> * Drop support of this release line
> >>>> * Delete the branch
> >>>>
> >>>> ## 1.1.x line
> >>>>
> >>>> First release: July 2011 (two years old)
> >>>>
> >>>> No unreleased changes.
> >>>>
> >>>> Recommendation:
> >>>>
> >>>> * Drop support of this release line
> >>>> * Delete the branch
> >>>>
> >>>> ## 1.2.x line
> >>>>
> >>>> First release: April 2012 (one year old)
> >>>>
> >>>> No unreleased changes.
> >>>>
> >>>> 1.3.x line is backwards compatible with 1.2.x.
> >>>>
> >>>> Recommendation:
> >>>>
> >>>> * Drop support of this release line
> >>>> * Delete the branch
> >>>>
> >>>> ## 1.3.x line
> >>>>
> >>>> First release: April 2013 (one month old)
> >>>>
> >>>> Unreleased changes:
> >>>>
> >>>> * Whatever bugfixes are on master or in branches right now.
> >>>>
> >>>> Recommendation:
> >>>>
> >>>> * Release 1.3.1 this month.
> >>>>
> >>>> Thanks,
> >>>>
> >>>> --
> >>>> NS
> >>>
> >>>
> >>>
> >>> --
> >>> NS
> >
> >
> >
> > --
> > NS
>
--
NS
Re: [DISCUSS] Release clean-up (delete ALL the branches!)
Posted by Jan Lehnardt <ja...@apache.org>.
On 18.05.2013, at 18:43, Noah Slater <ns...@apache.org> wrote:
> Unfortunately, the deed is done. What is your reason for wanting to keep
> them around?
History :)
I have plenty of clones, so no worries :)
Jan
--
>
>
> On 18 May 2013 18:38, Jan Lehnardt <ja...@apache.org> wrote:
>
>> Ah wow, that's what I get for going on vacation with unread threads.
>>
>> I'm major -1 on deleting old release branches, but I'd be happy to have
>> them moved to an archived repository. For the time being, I'll keep them on
>> my GitHub.
>>
>> Cheers
>> Jan
>> --
>>
>> On 11.05.2013, at 17:31, Noah Slater <ns...@apache.org> wrote:
>>
>>> Thanks guys.
>>>
>>> All the Y.Y.x branches, with the exception of 1.3.x, have been deleted.
>>>
>>> The following releases have been archived:
>>>
>>> * 1.0.4
>>> * 1.1.2
>>> * 1.2.1
>>> * 1.2.2
>>>
>>> (Where archived means: removed from our wiki and dist dir.)
>>>
>>> I added the following to our CurrentReleases page:
>>>
>>> CouchDB uses [[http://semver.org/|semantic versioning]], so, in a
>> nutshell:
>>>
>>> * X.Y.Z equates to major version, minor version, and bugfix version.
>>> * The major version will be incremented every time we make backwards
>>> incompatible changes.
>>> * The minor version will be incremented every time we add backwards
>>> compatible features.
>>> * The patch version will be incremented every time we add backwards
>>> compatible fixes.
>>>
>>> We will support each major version for 12 months. So, if 1.0.0 was
>> released
>>> on 2010-01-01, then we would features and fixes to it until 2011-01-01.
>>> After 12 months have passed, we may continue to release fixes for
>> critical
>>> security issues, but these will be in the form of patches.
>>>
>>> Note that the upgrade path for minor versions is to update the latest
>> minor
>>> version. We will not continue to release bugfix versions for an old minor
>>> version. That is, 1.1.0 immediately supersedes 1.0.x, and no more fixes
>>> will be made on the 1.0.x line. Similarly, 1.2.0 immediately supersedes
>>> 1.1.x.
>>>
>>>
>>>
>>> On 7 May 2013 19:34, Noah Slater <ns...@apache.org> wrote:
>>>
>>>> Devs,
>>>>
>>>> We're switching over to time-based releases.
>>>>
>>>> I took a moment to review our existing release branches today, and I
>> have
>>>> prepared a list of recommendations for you. Please review these and
>> give me
>>>> feedback.
>>>>
>>>> By "drop support" I mean "make official" and while this is ostensibly
>> the
>>>> case for a few of these, what I _really_ mean is "delete the branch". I
>> see
>>>> no reason to keep this stuff around. It would make my life a lot easier
>> if
>>>> we could clean this stuff up.
>>>>
>>>> I'm not a Git expert, so I am relying on someone to sanity check this.
>>>> Remember: if we ever want to patch up a security issue in an unsupported
>>>> release, we will be issuing a patch. So I am assuming what we'll want
>> to do
>>>> is patch against the last tag for that release line. No need for the
>> branch
>>>> at all as far as I can tell.
>>>>
>>>> If nobody objects in 72 hours, I will assume lazy consensus and proceed.
>>>>
>>>> ## 0.10.x line and before
>>>>
>>>> Really old stuff.
>>>>
>>>> Recommendation:
>>>>
>>>> * Drop support of these release lines
>>>> * Delete the branches
>>>>
>>>> ## 0.11.x line
>>>>
>>>> First release: March 2010 (three years old)
>>>>
>>>> Unreleased changes:
>>>>
>>>> * Fix for frequently edited documents in multi-master deployments being
>>>> duplicated in _changes and _all_docs.
>>>>
>>>> Recommendation:
>>>>
>>>> * Do not release these changes
>>>> * Drop support of this release line
>>>> * Delete the branch
>>>>
>>>> ## 1.0.x line
>>>>
>>>> First release: July 2010 (three years old)
>>>>
>>>> No unreleased changes.
>>>>
>>>> Recommendation:
>>>>
>>>> * Drop support of this release line
>>>> * Delete the branch
>>>>
>>>> ## 1.1.x line
>>>>
>>>> First release: July 2011 (two years old)
>>>>
>>>> No unreleased changes.
>>>>
>>>> Recommendation:
>>>>
>>>> * Drop support of this release line
>>>> * Delete the branch
>>>>
>>>> ## 1.2.x line
>>>>
>>>> First release: April 2012 (one year old)
>>>>
>>>> No unreleased changes.
>>>>
>>>> 1.3.x line is backwards compatible with 1.2.x.
>>>>
>>>> Recommendation:
>>>>
>>>> * Drop support of this release line
>>>> * Delete the branch
>>>>
>>>> ## 1.3.x line
>>>>
>>>> First release: April 2013 (one month old)
>>>>
>>>> Unreleased changes:
>>>>
>>>> * Whatever bugfixes are on master or in branches right now.
>>>>
>>>> Recommendation:
>>>>
>>>> * Release 1.3.1 this month.
>>>>
>>>> Thanks,
>>>>
>>>> --
>>>> NS
>>>
>>>
>>>
>>> --
>>> NS
>
>
>
> --
> NS
Re: [DISCUSS] Release clean-up (delete ALL the branches!)
Posted by Noah Slater <ns...@apache.org>.
Unfortunately, the deed is done. What is your reason for wanting to keep
them around?
On 18 May 2013 18:38, Jan Lehnardt <ja...@apache.org> wrote:
> Ah wow, that's what I get for going on vacation with unread threads.
>
> I'm major -1 on deleting old release branches, but I'd be happy to have
> them moved to an archived repository. For the time being, I'll keep them on
> my GitHub.
>
> Cheers
> Jan
> --
>
> On 11.05.2013, at 17:31, Noah Slater <ns...@apache.org> wrote:
>
> > Thanks guys.
> >
> > All the Y.Y.x branches, with the exception of 1.3.x, have been deleted.
> >
> > The following releases have been archived:
> >
> > * 1.0.4
> > * 1.1.2
> > * 1.2.1
> > * 1.2.2
> >
> > (Where archived means: removed from our wiki and dist dir.)
> >
> > I added the following to our CurrentReleases page:
> >
> > CouchDB uses [[http://semver.org/|semantic versioning]], so, in a
> nutshell:
> >
> > * X.Y.Z equates to major version, minor version, and bugfix version.
> > * The major version will be incremented every time we make backwards
> > incompatible changes.
> > * The minor version will be incremented every time we add backwards
> > compatible features.
> > * The patch version will be incremented every time we add backwards
> > compatible fixes.
> >
> > We will support each major version for 12 months. So, if 1.0.0 was
> released
> > on 2010-01-01, then we would features and fixes to it until 2011-01-01.
> > After 12 months have passed, we may continue to release fixes for
> critical
> > security issues, but these will be in the form of patches.
> >
> > Note that the upgrade path for minor versions is to update the latest
> minor
> > version. We will not continue to release bugfix versions for an old minor
> > version. That is, 1.1.0 immediately supersedes 1.0.x, and no more fixes
> > will be made on the 1.0.x line. Similarly, 1.2.0 immediately supersedes
> > 1.1.x.
> >
> >
> >
> > On 7 May 2013 19:34, Noah Slater <ns...@apache.org> wrote:
> >
> >> Devs,
> >>
> >> We're switching over to time-based releases.
> >>
> >> I took a moment to review our existing release branches today, and I
> have
> >> prepared a list of recommendations for you. Please review these and
> give me
> >> feedback.
> >>
> >> By "drop support" I mean "make official" and while this is ostensibly
> the
> >> case for a few of these, what I _really_ mean is "delete the branch". I
> see
> >> no reason to keep this stuff around. It would make my life a lot easier
> if
> >> we could clean this stuff up.
> >>
> >> I'm not a Git expert, so I am relying on someone to sanity check this.
> >> Remember: if we ever want to patch up a security issue in an unsupported
> >> release, we will be issuing a patch. So I am assuming what we'll want
> to do
> >> is patch against the last tag for that release line. No need for the
> branch
> >> at all as far as I can tell.
> >>
> >> If nobody objects in 72 hours, I will assume lazy consensus and proceed.
> >>
> >> ## 0.10.x line and before
> >>
> >> Really old stuff.
> >>
> >> Recommendation:
> >>
> >> * Drop support of these release lines
> >> * Delete the branches
> >>
> >> ## 0.11.x line
> >>
> >> First release: March 2010 (three years old)
> >>
> >> Unreleased changes:
> >>
> >> * Fix for frequently edited documents in multi-master deployments being
> >> duplicated in _changes and _all_docs.
> >>
> >> Recommendation:
> >>
> >> * Do not release these changes
> >> * Drop support of this release line
> >> * Delete the branch
> >>
> >> ## 1.0.x line
> >>
> >> First release: July 2010 (three years old)
> >>
> >> No unreleased changes.
> >>
> >> Recommendation:
> >>
> >> * Drop support of this release line
> >> * Delete the branch
> >>
> >> ## 1.1.x line
> >>
> >> First release: July 2011 (two years old)
> >>
> >> No unreleased changes.
> >>
> >> Recommendation:
> >>
> >> * Drop support of this release line
> >> * Delete the branch
> >>
> >> ## 1.2.x line
> >>
> >> First release: April 2012 (one year old)
> >>
> >> No unreleased changes.
> >>
> >> 1.3.x line is backwards compatible with 1.2.x.
> >>
> >> Recommendation:
> >>
> >> * Drop support of this release line
> >> * Delete the branch
> >>
> >> ## 1.3.x line
> >>
> >> First release: April 2013 (one month old)
> >>
> >> Unreleased changes:
> >>
> >> * Whatever bugfixes are on master or in branches right now.
> >>
> >> Recommendation:
> >>
> >> * Release 1.3.1 this month.
> >>
> >> Thanks,
> >>
> >> --
> >> NS
> >
> >
> >
> > --
> > NS
>
--
NS
Re: [DISCUSS] Release clean-up (delete ALL the branches!)
Posted by Jan Lehnardt <ja...@apache.org>.
Ah wow, that's what I get for going on vacation with unread threads.
I'm major -1 on deleting old release branches, but I'd be happy to have them moved to an archived repository. For the time being, I'll keep them on my GitHub.
Cheers
Jan
--
On 11.05.2013, at 17:31, Noah Slater <ns...@apache.org> wrote:
> Thanks guys.
>
> All the Y.Y.x branches, with the exception of 1.3.x, have been deleted.
>
> The following releases have been archived:
>
> * 1.0.4
> * 1.1.2
> * 1.2.1
> * 1.2.2
>
> (Where archived means: removed from our wiki and dist dir.)
>
> I added the following to our CurrentReleases page:
>
> CouchDB uses [[http://semver.org/|semantic versioning]], so, in a nutshell:
>
> * X.Y.Z equates to major version, minor version, and bugfix version.
> * The major version will be incremented every time we make backwards
> incompatible changes.
> * The minor version will be incremented every time we add backwards
> compatible features.
> * The patch version will be incremented every time we add backwards
> compatible fixes.
>
> We will support each major version for 12 months. So, if 1.0.0 was released
> on 2010-01-01, then we would features and fixes to it until 2011-01-01.
> After 12 months have passed, we may continue to release fixes for critical
> security issues, but these will be in the form of patches.
>
> Note that the upgrade path for minor versions is to update the latest minor
> version. We will not continue to release bugfix versions for an old minor
> version. That is, 1.1.0 immediately supersedes 1.0.x, and no more fixes
> will be made on the 1.0.x line. Similarly, 1.2.0 immediately supersedes
> 1.1.x.
>
>
>
> On 7 May 2013 19:34, Noah Slater <ns...@apache.org> wrote:
>
>> Devs,
>>
>> We're switching over to time-based releases.
>>
>> I took a moment to review our existing release branches today, and I have
>> prepared a list of recommendations for you. Please review these and give me
>> feedback.
>>
>> By "drop support" I mean "make official" and while this is ostensibly the
>> case for a few of these, what I _really_ mean is "delete the branch". I see
>> no reason to keep this stuff around. It would make my life a lot easier if
>> we could clean this stuff up.
>>
>> I'm not a Git expert, so I am relying on someone to sanity check this.
>> Remember: if we ever want to patch up a security issue in an unsupported
>> release, we will be issuing a patch. So I am assuming what we'll want to do
>> is patch against the last tag for that release line. No need for the branch
>> at all as far as I can tell.
>>
>> If nobody objects in 72 hours, I will assume lazy consensus and proceed.
>>
>> ## 0.10.x line and before
>>
>> Really old stuff.
>>
>> Recommendation:
>>
>> * Drop support of these release lines
>> * Delete the branches
>>
>> ## 0.11.x line
>>
>> First release: March 2010 (three years old)
>>
>> Unreleased changes:
>>
>> * Fix for frequently edited documents in multi-master deployments being
>> duplicated in _changes and _all_docs.
>>
>> Recommendation:
>>
>> * Do not release these changes
>> * Drop support of this release line
>> * Delete the branch
>>
>> ## 1.0.x line
>>
>> First release: July 2010 (three years old)
>>
>> No unreleased changes.
>>
>> Recommendation:
>>
>> * Drop support of this release line
>> * Delete the branch
>>
>> ## 1.1.x line
>>
>> First release: July 2011 (two years old)
>>
>> No unreleased changes.
>>
>> Recommendation:
>>
>> * Drop support of this release line
>> * Delete the branch
>>
>> ## 1.2.x line
>>
>> First release: April 2012 (one year old)
>>
>> No unreleased changes.
>>
>> 1.3.x line is backwards compatible with 1.2.x.
>>
>> Recommendation:
>>
>> * Drop support of this release line
>> * Delete the branch
>>
>> ## 1.3.x line
>>
>> First release: April 2013 (one month old)
>>
>> Unreleased changes:
>>
>> * Whatever bugfixes are on master or in branches right now.
>>
>> Recommendation:
>>
>> * Release 1.3.1 this month.
>>
>> Thanks,
>>
>> --
>> NS
>
>
>
> --
> NS
Re: [DISCUSS] Release clean-up (delete ALL the branches!)
Posted by Noah Slater <ns...@apache.org>.
Yep!
http://archive.apache.org/dist/couchdb/
On 16 May 2013 20:53, Joan Touzet <wo...@apache.org> wrote:
> On Sat, May 11, 2013 at 05:31:18PM +0100, Noah Slater wrote:
> > Thanks guys.
> >
> > All the Y.Y.x branches, with the exception of 1.3.x, have been deleted.
> >
> > The following releases have been archived:
> >
> > * 1.0.4
> > * 1.1.2
> > * 1.2.1
> > * 1.2.2
> >
> > (Where archived means: removed from our wiki and dist dir.)
>
> Speaking as an amateur code archivist, is there a "final resting place"
> for these bits anywhere? It's always interesting to go back in the
> life of a project in specific situations, and tarballs make that easy.
>
> --
> Joan Touzet | joant@atypical.net | wohali everywhere else
>
--
NS
Re: [DISCUSS] Release clean-up (delete ALL the branches!)
Posted by Joan Touzet <wo...@apache.org>.
On Sat, May 11, 2013 at 05:31:18PM +0100, Noah Slater wrote:
> Thanks guys.
>
> All the Y.Y.x branches, with the exception of 1.3.x, have been deleted.
>
> The following releases have been archived:
>
> * 1.0.4
> * 1.1.2
> * 1.2.1
> * 1.2.2
>
> (Where archived means: removed from our wiki and dist dir.)
Speaking as an amateur code archivist, is there a "final resting place"
for these bits anywhere? It's always interesting to go back in the
life of a project in specific situations, and tarballs make that easy.
--
Joan Touzet | joant@atypical.net | wohali everywhere else
Re: [DISCUSS] Release clean-up (delete ALL the branches!)
Posted by Noah Slater <ns...@apache.org>.
Thanks guys.
All the Y.Y.x branches, with the exception of 1.3.x, have been deleted.
The following releases have been archived:
* 1.0.4
* 1.1.2
* 1.2.1
* 1.2.2
(Where archived means: removed from our wiki and dist dir.)
I added the following to our CurrentReleases page:
CouchDB uses [[http://semver.org/|semantic versioning]], so, in a nutshell:
* X.Y.Z equates to major version, minor version, and bugfix version.
* The major version will be incremented every time we make backwards
incompatible changes.
* The minor version will be incremented every time we add backwards
compatible features.
* The patch version will be incremented every time we add backwards
compatible fixes.
We will support each major version for 12 months. So, if 1.0.0 was released
on 2010-01-01, then we would features and fixes to it until 2011-01-01.
After 12 months have passed, we may continue to release fixes for critical
security issues, but these will be in the form of patches.
Note that the upgrade path for minor versions is to update the latest minor
version. We will not continue to release bugfix versions for an old minor
version. That is, 1.1.0 immediately supersedes 1.0.x, and no more fixes
will be made on the 1.0.x line. Similarly, 1.2.0 immediately supersedes
1.1.x.
On 7 May 2013 19:34, Noah Slater <ns...@apache.org> wrote:
> Devs,
>
> We're switching over to time-based releases.
>
> I took a moment to review our existing release branches today, and I have
> prepared a list of recommendations for you. Please review these and give me
> feedback.
>
> By "drop support" I mean "make official" and while this is ostensibly the
> case for a few of these, what I _really_ mean is "delete the branch". I see
> no reason to keep this stuff around. It would make my life a lot easier if
> we could clean this stuff up.
>
> I'm not a Git expert, so I am relying on someone to sanity check this.
> Remember: if we ever want to patch up a security issue in an unsupported
> release, we will be issuing a patch. So I am assuming what we'll want to do
> is patch against the last tag for that release line. No need for the branch
> at all as far as I can tell.
>
> If nobody objects in 72 hours, I will assume lazy consensus and proceed.
>
> ## 0.10.x line and before
>
> Really old stuff.
>
> Recommendation:
>
> * Drop support of these release lines
> * Delete the branches
>
> ## 0.11.x line
>
> First release: March 2010 (three years old)
>
> Unreleased changes:
>
> * Fix for frequently edited documents in multi-master deployments being
> duplicated in _changes and _all_docs.
>
> Recommendation:
>
> * Do not release these changes
> * Drop support of this release line
> * Delete the branch
>
> ## 1.0.x line
>
> First release: July 2010 (three years old)
>
> No unreleased changes.
>
> Recommendation:
>
> * Drop support of this release line
> * Delete the branch
>
> ## 1.1.x line
>
> First release: July 2011 (two years old)
>
> No unreleased changes.
>
> Recommendation:
>
> * Drop support of this release line
> * Delete the branch
>
> ## 1.2.x line
>
> First release: April 2012 (one year old)
>
> No unreleased changes.
>
> 1.3.x line is backwards compatible with 1.2.x.
>
> Recommendation:
>
> * Drop support of this release line
> * Delete the branch
>
> ## 1.3.x line
>
> First release: April 2013 (one month old)
>
> Unreleased changes:
>
> * Whatever bugfixes are on master or in branches right now.
>
> Recommendation:
>
> * Release 1.3.1 this month.
>
> Thanks,
>
> --
> NS
>
--
NS
Re: [DISCUSS] Release clean-up (delete ALL the branches!)
Posted by Ryan Ramage <ry...@gmail.com>.
+1
On Wed, May 8, 2013 at 4:30 PM, Wendall Cada <we...@apache.org> wrote:
> +1
>
> On 05/07/2013 11:34 AM, Noah Slater wrote:
>
>> Devs,
>>
>> We're switching over to time-based releases.
>>
>> I took a moment to review our existing release branches today, and I have
>> prepared a list of recommendations for you. Please review these and give
>> me
>> feedback.
>>
>> By "drop support" I mean "make official" and while this is ostensibly the
>> case for a few of these, what I _really_ mean is "delete the branch". I
>> see
>> no reason to keep this stuff around. It would make my life a lot easier if
>> we could clean this stuff up.
>>
>> I'm not a Git expert, so I am relying on someone to sanity check this.
>> Remember: if we ever want to patch up a security issue in an unsupported
>> release, we will be issuing a patch. So I am assuming what we'll want to
>> do
>> is patch against the last tag for that release line. No need for the
>> branch
>> at all as far as I can tell.
>>
>> If nobody objects in 72 hours, I will assume lazy consensus and proceed.
>>
>> ## 0.10.x line and before
>>
>> Really old stuff.
>>
>> Recommendation:
>>
>> * Drop support of these release lines
>> * Delete the branches
>>
>> ## 0.11.x line
>>
>> First release: March 2010 (three years old)
>>
>> Unreleased changes:
>>
>> * Fix for frequently edited documents in multi-master deployments being
>> duplicated in _changes and _all_docs.
>>
>> Recommendation:
>>
>> * Do not release these changes
>> * Drop support of this release line
>> * Delete the branch
>>
>> ## 1.0.x line
>>
>> First release: July 2010 (three years old)
>>
>> No unreleased changes.
>>
>> Recommendation:
>>
>> * Drop support of this release line
>> * Delete the branch
>>
>> ## 1.1.x line
>>
>> First release: July 2011 (two years old)
>>
>> No unreleased changes.
>>
>> Recommendation:
>>
>> * Drop support of this release line
>> * Delete the branch
>>
>> ## 1.2.x line
>>
>> First release: April 2012 (one year old)
>>
>> No unreleased changes.
>>
>> 1.3.x line is backwards compatible with 1.2.x.
>>
>> Recommendation:
>>
>> * Drop support of this release line
>> * Delete the branch
>>
>> ## 1.3.x line
>>
>> First release: April 2013 (one month old)
>>
>> Unreleased changes:
>>
>> * Whatever bugfixes are on master or in branches right now.
>>
>> Recommendation:
>>
>> * Release 1.3.1 this month.
>>
>> Thanks,
>>
>>
>
Re: [DISCUSS] Release clean-up (delete ALL the branches!)
Posted by Wendall Cada <we...@apache.org>.
+1
On 05/07/2013 11:34 AM, Noah Slater wrote:
> Devs,
>
> We're switching over to time-based releases.
>
> I took a moment to review our existing release branches today, and I have
> prepared a list of recommendations for you. Please review these and give me
> feedback.
>
> By "drop support" I mean "make official" and while this is ostensibly the
> case for a few of these, what I _really_ mean is "delete the branch". I see
> no reason to keep this stuff around. It would make my life a lot easier if
> we could clean this stuff up.
>
> I'm not a Git expert, so I am relying on someone to sanity check this.
> Remember: if we ever want to patch up a security issue in an unsupported
> release, we will be issuing a patch. So I am assuming what we'll want to do
> is patch against the last tag for that release line. No need for the branch
> at all as far as I can tell.
>
> If nobody objects in 72 hours, I will assume lazy consensus and proceed.
>
> ## 0.10.x line and before
>
> Really old stuff.
>
> Recommendation:
>
> * Drop support of these release lines
> * Delete the branches
>
> ## 0.11.x line
>
> First release: March 2010 (three years old)
>
> Unreleased changes:
>
> * Fix for frequently edited documents in multi-master deployments being
> duplicated in _changes and _all_docs.
>
> Recommendation:
>
> * Do not release these changes
> * Drop support of this release line
> * Delete the branch
>
> ## 1.0.x line
>
> First release: July 2010 (three years old)
>
> No unreleased changes.
>
> Recommendation:
>
> * Drop support of this release line
> * Delete the branch
>
> ## 1.1.x line
>
> First release: July 2011 (two years old)
>
> No unreleased changes.
>
> Recommendation:
>
> * Drop support of this release line
> * Delete the branch
>
> ## 1.2.x line
>
> First release: April 2012 (one year old)
>
> No unreleased changes.
>
> 1.3.x line is backwards compatible with 1.2.x.
>
> Recommendation:
>
> * Drop support of this release line
> * Delete the branch
>
> ## 1.3.x line
>
> First release: April 2013 (one month old)
>
> Unreleased changes:
>
> * Whatever bugfixes are on master or in branches right now.
>
> Recommendation:
>
> * Release 1.3.1 this month.
>
> Thanks,
>
Re: [DISCUSS] Release clean-up (delete ALL the branches!)
Posted by Benoit Chesneau <bc...@gmail.com>.
+1
On Tue, May 7, 2013 at 8:35 PM, Robert Newson <rn...@apache.org> wrote:
> +1
>
> On 7 May 2013 19:34, Noah Slater <ns...@apache.org> wrote:
>> Devs,
>>
>> We're switching over to time-based releases.
>>
>> I took a moment to review our existing release branches today, and I have
>> prepared a list of recommendations for you. Please review these and give me
>> feedback.
>>
>> By "drop support" I mean "make official" and while this is ostensibly the
>> case for a few of these, what I _really_ mean is "delete the branch". I see
>> no reason to keep this stuff around. It would make my life a lot easier if
>> we could clean this stuff up.
>>
>> I'm not a Git expert, so I am relying on someone to sanity check this.
>> Remember: if we ever want to patch up a security issue in an unsupported
>> release, we will be issuing a patch. So I am assuming what we'll want to do
>> is patch against the last tag for that release line. No need for the branch
>> at all as far as I can tell.
>>
>> If nobody objects in 72 hours, I will assume lazy consensus and proceed.
>>
>> ## 0.10.x line and before
>>
>> Really old stuff.
>>
>> Recommendation:
>>
>> * Drop support of these release lines
>> * Delete the branches
>>
>> ## 0.11.x line
>>
>> First release: March 2010 (three years old)
>>
>> Unreleased changes:
>>
>> * Fix for frequently edited documents in multi-master deployments being
>> duplicated in _changes and _all_docs.
>>
>> Recommendation:
>>
>> * Do not release these changes
>> * Drop support of this release line
>> * Delete the branch
>>
>> ## 1.0.x line
>>
>> First release: July 2010 (three years old)
>>
>> No unreleased changes.
>>
>> Recommendation:
>>
>> * Drop support of this release line
>> * Delete the branch
>>
>> ## 1.1.x line
>>
>> First release: July 2011 (two years old)
>>
>> No unreleased changes.
>>
>> Recommendation:
>>
>> * Drop support of this release line
>> * Delete the branch
>>
>> ## 1.2.x line
>>
>> First release: April 2012 (one year old)
>>
>> No unreleased changes.
>>
>> 1.3.x line is backwards compatible with 1.2.x.
>>
>> Recommendation:
>>
>> * Drop support of this release line
>> * Delete the branch
>>
>> ## 1.3.x line
>>
>> First release: April 2013 (one month old)
>>
>> Unreleased changes:
>>
>> * Whatever bugfixes are on master or in branches right now.
>>
>> Recommendation:
>>
>> * Release 1.3.1 this month.
>>
>> Thanks,
>>
>> --
>> NS
Re: [DISCUSS] Release clean-up (delete ALL the branches!)
Posted by Robert Newson <rn...@apache.org>.
+1
On 7 May 2013 19:34, Noah Slater <ns...@apache.org> wrote:
> Devs,
>
> We're switching over to time-based releases.
>
> I took a moment to review our existing release branches today, and I have
> prepared a list of recommendations for you. Please review these and give me
> feedback.
>
> By "drop support" I mean "make official" and while this is ostensibly the
> case for a few of these, what I _really_ mean is "delete the branch". I see
> no reason to keep this stuff around. It would make my life a lot easier if
> we could clean this stuff up.
>
> I'm not a Git expert, so I am relying on someone to sanity check this.
> Remember: if we ever want to patch up a security issue in an unsupported
> release, we will be issuing a patch. So I am assuming what we'll want to do
> is patch against the last tag for that release line. No need for the branch
> at all as far as I can tell.
>
> If nobody objects in 72 hours, I will assume lazy consensus and proceed.
>
> ## 0.10.x line and before
>
> Really old stuff.
>
> Recommendation:
>
> * Drop support of these release lines
> * Delete the branches
>
> ## 0.11.x line
>
> First release: March 2010 (three years old)
>
> Unreleased changes:
>
> * Fix for frequently edited documents in multi-master deployments being
> duplicated in _changes and _all_docs.
>
> Recommendation:
>
> * Do not release these changes
> * Drop support of this release line
> * Delete the branch
>
> ## 1.0.x line
>
> First release: July 2010 (three years old)
>
> No unreleased changes.
>
> Recommendation:
>
> * Drop support of this release line
> * Delete the branch
>
> ## 1.1.x line
>
> First release: July 2011 (two years old)
>
> No unreleased changes.
>
> Recommendation:
>
> * Drop support of this release line
> * Delete the branch
>
> ## 1.2.x line
>
> First release: April 2012 (one year old)
>
> No unreleased changes.
>
> 1.3.x line is backwards compatible with 1.2.x.
>
> Recommendation:
>
> * Drop support of this release line
> * Delete the branch
>
> ## 1.3.x line
>
> First release: April 2013 (one month old)
>
> Unreleased changes:
>
> * Whatever bugfixes are on master or in branches right now.
>
> Recommendation:
>
> * Release 1.3.1 this month.
>
> Thanks,
>
> --
> NS
Re: [DISCUSS] Release clean-up (delete ALL the branches!)
Posted by Noah Slater <ns...@apache.org>.
Joan,
1.2.x is forwards-compatible with 1.3.x, so there is no reason to keep it
around.
On 8 May 2013 18:06, Joan Touzet <wo...@apache.org> wrote:
> I don't know what the Apache stance is on things, but I'm -1 on deleting
> the 1.2.x branch. "n and n-1" support is fairly common, unless you want
> to consdier n == HEAD and n-1 == 1.3.x.
>
> Otherwise +1.
>
> -Joan
>
> On Tue, May 07, 2013 at 07:34:14PM +0100, Noah Slater wrote:
> > Devs,
> >
> > We're switching over to time-based releases.
> >
> > I took a moment to review our existing release branches today, and I have
> > prepared a list of recommendations for you. Please review these and give
> me
> > feedback.
> >
> > By "drop support" I mean "make official" and while this is ostensibly the
> > case for a few of these, what I _really_ mean is "delete the branch". I
> see
> > no reason to keep this stuff around. It would make my life a lot easier
> if
> > we could clean this stuff up.
> >
> > I'm not a Git expert, so I am relying on someone to sanity check this.
> > Remember: if we ever want to patch up a security issue in an unsupported
> > release, we will be issuing a patch. So I am assuming what we'll want to
> do
> > is patch against the last tag for that release line. No need for the
> branch
> > at all as far as I can tell.
> >
> > If nobody objects in 72 hours, I will assume lazy consensus and proceed.
> >
> > ## 0.10.x line and before
> >
> > Really old stuff.
> >
> > Recommendation:
> >
> > * Drop support of these release lines
> > * Delete the branches
> >
> > ## 0.11.x line
> >
> > First release: March 2010 (three years old)
> >
> > Unreleased changes:
> >
> > * Fix for frequently edited documents in multi-master deployments being
> > duplicated in _changes and _all_docs.
> >
> > Recommendation:
> >
> > * Do not release these changes
> > * Drop support of this release line
> > * Delete the branch
> >
> > ## 1.0.x line
> >
> > First release: July 2010 (three years old)
> >
> > No unreleased changes.
> >
> > Recommendation:
> >
> > * Drop support of this release line
> > * Delete the branch
> >
> > ## 1.1.x line
> >
> > First release: July 2011 (two years old)
> >
> > No unreleased changes.
> >
> > Recommendation:
> >
> > * Drop support of this release line
> > * Delete the branch
> >
> > ## 1.2.x line
> >
> > First release: April 2012 (one year old)
> >
> > No unreleased changes.
> >
> > 1.3.x line is backwards compatible with 1.2.x.
> >
> > Recommendation:
> >
> > * Drop support of this release line
> > * Delete the branch
> >
> > ## 1.3.x line
> >
> > First release: April 2013 (one month old)
> >
> > Unreleased changes:
> >
> > * Whatever bugfixes are on master or in branches right now.
> >
> > Recommendation:
> >
> > * Release 1.3.1 this month.
> >
> > Thanks,
> >
> > --
> > NS
>
> --
> Joan Touzet | joant@atypical.net | wohali everywhere else
>
--
NS
Re: [DISCUSS] Release clean-up (delete ALL the branches!)
Posted by Noah Slater <ns...@apache.org>.
Joan, agreed! We'd want to support the 1.x line for 12 months, I think.
On 8 May 2013 19:25, Joan Touzet <wo...@apache.org> wrote:
> OK, in that case when there's a 2.0 ready to go, we'd also support
> 1.latest for (some indefinite but non-zero period of time).
>
> You've convinced me, +1!
>
> On Wed, May 08, 2013 at 06:33:43PM +0100, Robert Newson wrote:
> > I'm +1 on 1.3.0 being the upgrade back for 1.2.anything in general.
> >
> > If we stick with semver this is the expected path.
> >
> > On 8 May 2013 18:26, Noah Slater <ns...@apache.org> wrote:
> > > *Noodles a little while longer...*
> > >
> > > In fact, I am not even sure why we recently did that 1.2.2 release.
> > > Unfortunately, I think we got into the habit of thinking that minor
> version
> > > numbers mean breaking changes. Because, in the past, this has sometimes
> > > been the case. For those people who wanted that fix in the 1.2.2, I
> should
> > > have said "please upgrade to 1.3". Unless there are breaking changes
> that I
> > > do not know about? (If there is, please tell me. There is nothing in
> NEWS
> > > or CHANGES that I can see.)
> > >
> > > What are your thoughts on this?
> > >
> > >
> > > On 8 May 2013 18:06, Joan Touzet <wo...@apache.org> wrote:
> > >
> > >> I don't know what the Apache stance is on things, but I'm -1 on
> deleting
> > >> the 1.2.x branch. "n and n-1" support is fairly common, unless you
> want
> > >> to consdier n == HEAD and n-1 == 1.3.x.
> > >>
> > >> Otherwise +1.
> > >>
> > >> -Joan
> > >>
> > >> On Tue, May 07, 2013 at 07:34:14PM +0100, Noah Slater wrote:
> > >> > Devs,
> > >> >
> > >> > We're switching over to time-based releases.
> > >> >
> > >> > I took a moment to review our existing release branches today, and
> I have
> > >> > prepared a list of recommendations for you. Please review these and
> give
> > >> me
> > >> > feedback.
> > >> >
> > >> > By "drop support" I mean "make official" and while this is
> ostensibly the
> > >> > case for a few of these, what I _really_ mean is "delete the
> branch". I
> > >> see
> > >> > no reason to keep this stuff around. It would make my life a lot
> easier
> > >> if
> > >> > we could clean this stuff up.
> > >> >
> > >> > I'm not a Git expert, so I am relying on someone to sanity check
> this.
> > >> > Remember: if we ever want to patch up a security issue in an
> unsupported
> > >> > release, we will be issuing a patch. So I am assuming what we'll
> want to
> > >> do
> > >> > is patch against the last tag for that release line. No need for the
> > >> branch
> > >> > at all as far as I can tell.
> > >> >
> > >> > If nobody objects in 72 hours, I will assume lazy consensus and
> proceed.
> > >> >
> > >> > ## 0.10.x line and before
> > >> >
> > >> > Really old stuff.
> > >> >
> > >> > Recommendation:
> > >> >
> > >> > * Drop support of these release lines
> > >> > * Delete the branches
> > >> >
> > >> > ## 0.11.x line
> > >> >
> > >> > First release: March 2010 (three years old)
> > >> >
> > >> > Unreleased changes:
> > >> >
> > >> > * Fix for frequently edited documents in multi-master deployments
> being
> > >> > duplicated in _changes and _all_docs.
> > >> >
> > >> > Recommendation:
> > >> >
> > >> > * Do not release these changes
> > >> > * Drop support of this release line
> > >> > * Delete the branch
> > >> >
> > >> > ## 1.0.x line
> > >> >
> > >> > First release: July 2010 (three years old)
> > >> >
> > >> > No unreleased changes.
> > >> >
> > >> > Recommendation:
> > >> >
> > >> > * Drop support of this release line
> > >> > * Delete the branch
> > >> >
> > >> > ## 1.1.x line
> > >> >
> > >> > First release: July 2011 (two years old)
> > >> >
> > >> > No unreleased changes.
> > >> >
> > >> > Recommendation:
> > >> >
> > >> > * Drop support of this release line
> > >> > * Delete the branch
> > >> >
> > >> > ## 1.2.x line
> > >> >
> > >> > First release: April 2012 (one year old)
> > >> >
> > >> > No unreleased changes.
> > >> >
> > >> > 1.3.x line is backwards compatible with 1.2.x.
> > >> >
> > >> > Recommendation:
> > >> >
> > >> > * Drop support of this release line
> > >> > * Delete the branch
> > >> >
> > >> > ## 1.3.x line
> > >> >
> > >> > First release: April 2013 (one month old)
> > >> >
> > >> > Unreleased changes:
> > >> >
> > >> > * Whatever bugfixes are on master or in branches right now.
> > >> >
> > >> > Recommendation:
> > >> >
> > >> > * Release 1.3.1 this month.
> > >> >
> > >> > Thanks,
> > >> >
> > >> > --
> > >> > NS
> > >>
> > >> --
> > >> Joan Touzet | joant@atypical.net | wohali everywhere else
> > >>
> > >
> > >
> > >
> > > --
> > > NS
>
> --
> Joan Touzet | joant@atypical.net | wohali everywhere else
>
--
NS
Re: [DISCUSS] Release clean-up (delete ALL the branches!)
Posted by Joan Touzet <wo...@apache.org>.
OK, in that case when there's a 2.0 ready to go, we'd also support
1.latest for (some indefinite but non-zero period of time).
You've convinced me, +1!
On Wed, May 08, 2013 at 06:33:43PM +0100, Robert Newson wrote:
> I'm +1 on 1.3.0 being the upgrade back for 1.2.anything in general.
>
> If we stick with semver this is the expected path.
>
> On 8 May 2013 18:26, Noah Slater <ns...@apache.org> wrote:
> > *Noodles a little while longer...*
> >
> > In fact, I am not even sure why we recently did that 1.2.2 release.
> > Unfortunately, I think we got into the habit of thinking that minor version
> > numbers mean breaking changes. Because, in the past, this has sometimes
> > been the case. For those people who wanted that fix in the 1.2.2, I should
> > have said "please upgrade to 1.3". Unless there are breaking changes that I
> > do not know about? (If there is, please tell me. There is nothing in NEWS
> > or CHANGES that I can see.)
> >
> > What are your thoughts on this?
> >
> >
> > On 8 May 2013 18:06, Joan Touzet <wo...@apache.org> wrote:
> >
> >> I don't know what the Apache stance is on things, but I'm -1 on deleting
> >> the 1.2.x branch. "n and n-1" support is fairly common, unless you want
> >> to consdier n == HEAD and n-1 == 1.3.x.
> >>
> >> Otherwise +1.
> >>
> >> -Joan
> >>
> >> On Tue, May 07, 2013 at 07:34:14PM +0100, Noah Slater wrote:
> >> > Devs,
> >> >
> >> > We're switching over to time-based releases.
> >> >
> >> > I took a moment to review our existing release branches today, and I have
> >> > prepared a list of recommendations for you. Please review these and give
> >> me
> >> > feedback.
> >> >
> >> > By "drop support" I mean "make official" and while this is ostensibly the
> >> > case for a few of these, what I _really_ mean is "delete the branch". I
> >> see
> >> > no reason to keep this stuff around. It would make my life a lot easier
> >> if
> >> > we could clean this stuff up.
> >> >
> >> > I'm not a Git expert, so I am relying on someone to sanity check this.
> >> > Remember: if we ever want to patch up a security issue in an unsupported
> >> > release, we will be issuing a patch. So I am assuming what we'll want to
> >> do
> >> > is patch against the last tag for that release line. No need for the
> >> branch
> >> > at all as far as I can tell.
> >> >
> >> > If nobody objects in 72 hours, I will assume lazy consensus and proceed.
> >> >
> >> > ## 0.10.x line and before
> >> >
> >> > Really old stuff.
> >> >
> >> > Recommendation:
> >> >
> >> > * Drop support of these release lines
> >> > * Delete the branches
> >> >
> >> > ## 0.11.x line
> >> >
> >> > First release: March 2010 (three years old)
> >> >
> >> > Unreleased changes:
> >> >
> >> > * Fix for frequently edited documents in multi-master deployments being
> >> > duplicated in _changes and _all_docs.
> >> >
> >> > Recommendation:
> >> >
> >> > * Do not release these changes
> >> > * Drop support of this release line
> >> > * Delete the branch
> >> >
> >> > ## 1.0.x line
> >> >
> >> > First release: July 2010 (three years old)
> >> >
> >> > No unreleased changes.
> >> >
> >> > Recommendation:
> >> >
> >> > * Drop support of this release line
> >> > * Delete the branch
> >> >
> >> > ## 1.1.x line
> >> >
> >> > First release: July 2011 (two years old)
> >> >
> >> > No unreleased changes.
> >> >
> >> > Recommendation:
> >> >
> >> > * Drop support of this release line
> >> > * Delete the branch
> >> >
> >> > ## 1.2.x line
> >> >
> >> > First release: April 2012 (one year old)
> >> >
> >> > No unreleased changes.
> >> >
> >> > 1.3.x line is backwards compatible with 1.2.x.
> >> >
> >> > Recommendation:
> >> >
> >> > * Drop support of this release line
> >> > * Delete the branch
> >> >
> >> > ## 1.3.x line
> >> >
> >> > First release: April 2013 (one month old)
> >> >
> >> > Unreleased changes:
> >> >
> >> > * Whatever bugfixes are on master or in branches right now.
> >> >
> >> > Recommendation:
> >> >
> >> > * Release 1.3.1 this month.
> >> >
> >> > Thanks,
> >> >
> >> > --
> >> > NS
> >>
> >> --
> >> Joan Touzet | joant@atypical.net | wohali everywhere else
> >>
> >
> >
> >
> > --
> > NS
--
Joan Touzet | joant@atypical.net | wohali everywhere else
Re: [DISCUSS] Release clean-up (delete ALL the branches!)
Posted by Robert Newson <rn...@apache.org>.
I'm +1 on 1.3.0 being the upgrade back for 1.2.anything in general.
If we stick with semver this is the expected path.
On 8 May 2013 18:26, Noah Slater <ns...@apache.org> wrote:
> *Noodles a little while longer...*
>
> In fact, I am not even sure why we recently did that 1.2.2 release.
> Unfortunately, I think we got into the habit of thinking that minor version
> numbers mean breaking changes. Because, in the past, this has sometimes
> been the case. For those people who wanted that fix in the 1.2.2, I should
> have said "please upgrade to 1.3". Unless there are breaking changes that I
> do not know about? (If there is, please tell me. There is nothing in NEWS
> or CHANGES that I can see.)
>
> What are your thoughts on this?
>
>
> On 8 May 2013 18:06, Joan Touzet <wo...@apache.org> wrote:
>
>> I don't know what the Apache stance is on things, but I'm -1 on deleting
>> the 1.2.x branch. "n and n-1" support is fairly common, unless you want
>> to consdier n == HEAD and n-1 == 1.3.x.
>>
>> Otherwise +1.
>>
>> -Joan
>>
>> On Tue, May 07, 2013 at 07:34:14PM +0100, Noah Slater wrote:
>> > Devs,
>> >
>> > We're switching over to time-based releases.
>> >
>> > I took a moment to review our existing release branches today, and I have
>> > prepared a list of recommendations for you. Please review these and give
>> me
>> > feedback.
>> >
>> > By "drop support" I mean "make official" and while this is ostensibly the
>> > case for a few of these, what I _really_ mean is "delete the branch". I
>> see
>> > no reason to keep this stuff around. It would make my life a lot easier
>> if
>> > we could clean this stuff up.
>> >
>> > I'm not a Git expert, so I am relying on someone to sanity check this.
>> > Remember: if we ever want to patch up a security issue in an unsupported
>> > release, we will be issuing a patch. So I am assuming what we'll want to
>> do
>> > is patch against the last tag for that release line. No need for the
>> branch
>> > at all as far as I can tell.
>> >
>> > If nobody objects in 72 hours, I will assume lazy consensus and proceed.
>> >
>> > ## 0.10.x line and before
>> >
>> > Really old stuff.
>> >
>> > Recommendation:
>> >
>> > * Drop support of these release lines
>> > * Delete the branches
>> >
>> > ## 0.11.x line
>> >
>> > First release: March 2010 (three years old)
>> >
>> > Unreleased changes:
>> >
>> > * Fix for frequently edited documents in multi-master deployments being
>> > duplicated in _changes and _all_docs.
>> >
>> > Recommendation:
>> >
>> > * Do not release these changes
>> > * Drop support of this release line
>> > * Delete the branch
>> >
>> > ## 1.0.x line
>> >
>> > First release: July 2010 (three years old)
>> >
>> > No unreleased changes.
>> >
>> > Recommendation:
>> >
>> > * Drop support of this release line
>> > * Delete the branch
>> >
>> > ## 1.1.x line
>> >
>> > First release: July 2011 (two years old)
>> >
>> > No unreleased changes.
>> >
>> > Recommendation:
>> >
>> > * Drop support of this release line
>> > * Delete the branch
>> >
>> > ## 1.2.x line
>> >
>> > First release: April 2012 (one year old)
>> >
>> > No unreleased changes.
>> >
>> > 1.3.x line is backwards compatible with 1.2.x.
>> >
>> > Recommendation:
>> >
>> > * Drop support of this release line
>> > * Delete the branch
>> >
>> > ## 1.3.x line
>> >
>> > First release: April 2013 (one month old)
>> >
>> > Unreleased changes:
>> >
>> > * Whatever bugfixes are on master or in branches right now.
>> >
>> > Recommendation:
>> >
>> > * Release 1.3.1 this month.
>> >
>> > Thanks,
>> >
>> > --
>> > NS
>>
>> --
>> Joan Touzet | joant@atypical.net | wohali everywhere else
>>
>
>
>
> --
> NS
Re: [DISCUSS] Release clean-up (delete ALL the branches!)
Posted by Noah Slater <ns...@apache.org>.
*Noodles a little while longer...*
In fact, I am not even sure why we recently did that 1.2.2 release.
Unfortunately, I think we got into the habit of thinking that minor version
numbers mean breaking changes. Because, in the past, this has sometimes
been the case. For those people who wanted that fix in the 1.2.2, I should
have said "please upgrade to 1.3". Unless there are breaking changes that I
do not know about? (If there is, please tell me. There is nothing in NEWS
or CHANGES that I can see.)
What are your thoughts on this?
On 8 May 2013 18:06, Joan Touzet <wo...@apache.org> wrote:
> I don't know what the Apache stance is on things, but I'm -1 on deleting
> the 1.2.x branch. "n and n-1" support is fairly common, unless you want
> to consdier n == HEAD and n-1 == 1.3.x.
>
> Otherwise +1.
>
> -Joan
>
> On Tue, May 07, 2013 at 07:34:14PM +0100, Noah Slater wrote:
> > Devs,
> >
> > We're switching over to time-based releases.
> >
> > I took a moment to review our existing release branches today, and I have
> > prepared a list of recommendations for you. Please review these and give
> me
> > feedback.
> >
> > By "drop support" I mean "make official" and while this is ostensibly the
> > case for a few of these, what I _really_ mean is "delete the branch". I
> see
> > no reason to keep this stuff around. It would make my life a lot easier
> if
> > we could clean this stuff up.
> >
> > I'm not a Git expert, so I am relying on someone to sanity check this.
> > Remember: if we ever want to patch up a security issue in an unsupported
> > release, we will be issuing a patch. So I am assuming what we'll want to
> do
> > is patch against the last tag for that release line. No need for the
> branch
> > at all as far as I can tell.
> >
> > If nobody objects in 72 hours, I will assume lazy consensus and proceed.
> >
> > ## 0.10.x line and before
> >
> > Really old stuff.
> >
> > Recommendation:
> >
> > * Drop support of these release lines
> > * Delete the branches
> >
> > ## 0.11.x line
> >
> > First release: March 2010 (three years old)
> >
> > Unreleased changes:
> >
> > * Fix for frequently edited documents in multi-master deployments being
> > duplicated in _changes and _all_docs.
> >
> > Recommendation:
> >
> > * Do not release these changes
> > * Drop support of this release line
> > * Delete the branch
> >
> > ## 1.0.x line
> >
> > First release: July 2010 (three years old)
> >
> > No unreleased changes.
> >
> > Recommendation:
> >
> > * Drop support of this release line
> > * Delete the branch
> >
> > ## 1.1.x line
> >
> > First release: July 2011 (two years old)
> >
> > No unreleased changes.
> >
> > Recommendation:
> >
> > * Drop support of this release line
> > * Delete the branch
> >
> > ## 1.2.x line
> >
> > First release: April 2012 (one year old)
> >
> > No unreleased changes.
> >
> > 1.3.x line is backwards compatible with 1.2.x.
> >
> > Recommendation:
> >
> > * Drop support of this release line
> > * Delete the branch
> >
> > ## 1.3.x line
> >
> > First release: April 2013 (one month old)
> >
> > Unreleased changes:
> >
> > * Whatever bugfixes are on master or in branches right now.
> >
> > Recommendation:
> >
> > * Release 1.3.1 this month.
> >
> > Thanks,
> >
> > --
> > NS
>
> --
> Joan Touzet | joant@atypical.net | wohali everywhere else
>
--
NS
Re: [DISCUSS] Release clean-up (delete ALL the branches!)
Posted by Joan Touzet <wo...@apache.org>.
I don't know what the Apache stance is on things, but I'm -1 on deleting
the 1.2.x branch. "n and n-1" support is fairly common, unless you want
to consdier n == HEAD and n-1 == 1.3.x.
Otherwise +1.
-Joan
On Tue, May 07, 2013 at 07:34:14PM +0100, Noah Slater wrote:
> Devs,
>
> We're switching over to time-based releases.
>
> I took a moment to review our existing release branches today, and I have
> prepared a list of recommendations for you. Please review these and give me
> feedback.
>
> By "drop support" I mean "make official" and while this is ostensibly the
> case for a few of these, what I _really_ mean is "delete the branch". I see
> no reason to keep this stuff around. It would make my life a lot easier if
> we could clean this stuff up.
>
> I'm not a Git expert, so I am relying on someone to sanity check this.
> Remember: if we ever want to patch up a security issue in an unsupported
> release, we will be issuing a patch. So I am assuming what we'll want to do
> is patch against the last tag for that release line. No need for the branch
> at all as far as I can tell.
>
> If nobody objects in 72 hours, I will assume lazy consensus and proceed.
>
> ## 0.10.x line and before
>
> Really old stuff.
>
> Recommendation:
>
> * Drop support of these release lines
> * Delete the branches
>
> ## 0.11.x line
>
> First release: March 2010 (three years old)
>
> Unreleased changes:
>
> * Fix for frequently edited documents in multi-master deployments being
> duplicated in _changes and _all_docs.
>
> Recommendation:
>
> * Do not release these changes
> * Drop support of this release line
> * Delete the branch
>
> ## 1.0.x line
>
> First release: July 2010 (three years old)
>
> No unreleased changes.
>
> Recommendation:
>
> * Drop support of this release line
> * Delete the branch
>
> ## 1.1.x line
>
> First release: July 2011 (two years old)
>
> No unreleased changes.
>
> Recommendation:
>
> * Drop support of this release line
> * Delete the branch
>
> ## 1.2.x line
>
> First release: April 2012 (one year old)
>
> No unreleased changes.
>
> 1.3.x line is backwards compatible with 1.2.x.
>
> Recommendation:
>
> * Drop support of this release line
> * Delete the branch
>
> ## 1.3.x line
>
> First release: April 2013 (one month old)
>
> Unreleased changes:
>
> * Whatever bugfixes are on master or in branches right now.
>
> Recommendation:
>
> * Release 1.3.1 this month.
>
> Thanks,
>
> --
> NS
--
Joan Touzet | joant@atypical.net | wohali everywhere else