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] Archive Apache CouchDB 1.2.1
Date Sun, 26 May 2013 13:47:59 GMT
You make a compelling argument, Jan. Do you think we should move the 1.2.2
release back into the dist dir, or should we just keep this in mind for
future releases?


On 26 May 2013 14:44, Jan Lehnardt <jan@apache.org> wrote:

>
> On May 23, 2013, at 08:20 , Noah Slater <nslater@apache.org> wrote:
>
> > Dave,
> >
> > See the following thread:
> >
> > [DISCUSS] Release clean-up (delete ALL the branches!)
> > http://markmail.org/message/rrz5yl6fig2vnfu5
> >
> > Specifically, my proposal to drop support for the 1.2.x line for the
> > following reasons:
> >
> > * The 1.2.x line is over a year old
> > * The 1.3.x line is upwards compatible
> >
> > On 23 May 2013 10:30, Dave Cottlehuber <dch@jsonified.com> wrote:
> >
> >>
> >> But does that mean we only keep the latest version on the mirrors?
> >>
> >
> > Yep.
> >
> > But... All of the 1.2.x releases are available here:
> >
> > http://archive.apache.org/dist/couchdb/
> >
> > What I am proposing we do is that when we drop support* for a release, we
> > remove it from our active dist dir. The files will always be available in
> > our archive dist dir, so the releases are still available, should you
> need
> > them.
> >
> > What we want to avoid is people going to our active dist dir, seeing
> 1.2.2
> > and thinking "ah, this is a supported release. I'll download and install
> > it." Because at this point, we don't want people to do that any more. (We
> > want them do use 1.3.0.)
>
> People don’t go to dist/ folders. They click on links on the website or
> type `apt-get install couchdb`. I don’t think “making dist/ look recent”
> is a primary objective here.
>
> In fact, I think there is a danger / inconvenience here. We have little
> control over what downstream packagers reference, let alone, what state
> downstream user’s package repository references are in. I recently had
> a support case where we had one tarball removed from dist and the person
> still had a little bit out of date (but not by much) brew repo, so
> `brew install couchdb` failed with tarball not found, which doesn’t make
> obvious that `brew update` (refreshing the available package list) would
> help.
>
> I am sure someone can find someone else to blame for this, but I am not
> interested in that, I am just concerned with the experience of our users
> and we’d have a better situation, if we had them let install a slightly
> (it was a .z-level version bump) out of date version than the
> *very* latest.
>
>
>
> tl;dr: Supporting a release is different from keeping a tarball around
> on its original release URL and I think the latter timeframe should be
> longer.
>
> Best
> Jan
> --
>
>
>
>
> > * When I say "drop support" I mean "we don't backport features or
> bugfixes
> > to this line any more".
>
>
>
> >
> > My apologies if we've already agreed this & it is just sinking into my
> >> little bear brain today.
> >>
> >
> > No worries. It seems this has caught a few people by surprise. We're
> > changing a system we've been using for half a decade, so that's to be
> > expected. :)
> >
> >
> >> TL;DR does it make sense to keep the n and n-1 active releases on the
> >> mirrors, or shall I just point people to
> >> http://archive.apache.org/dist/couchdb/binary/win/1.2.2/  etc? Maybe
> >> add a link on our website?
> >>
> >
> > Why would we want to keep n-1 active release on the mirrors?
> >
> > We shouldn't be encouraging anybody to download 1.2.2 any longer, so why
> > would we want to keep it around?
> >
> > --
> > NS
>
>


-- 
NS

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