couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@apache.org>
Subject Re: [DISCUSS] Release clean-up (delete ALL the branches!)
Date Sat, 18 May 2013 17:56:29 GMT
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 <jan@apache.org> wrote:

>
>
> On 18.05.2013, at 18:43, Noah Slater <nslater@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 <jan@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 <nslater@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 <nslater@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message