On May 23, 2013, at 08:20 , Noah Slater <[email protected]> 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 <[email protected]> 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
