couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: [DISCUSS] Archive Apache CouchDB 1.2.1
Date Sun, 26 May 2013 13:50:23 GMT

On May 26, 2013, at 09:47 , Noah Slater <nslater@apache.org> wrote:

> 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?

I don’t think it is too much effort to keep it around, is it?

Best
Jan
--



> 
> 
> 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
View raw message