My point is: it's has already been removed. So I'm wondering if you think we should move it back. We've never done something like this, so I wanna be sure what you're proposing. :)
On 26 May 2013 14:50, Jan Lehnardt <[email protected]> wrote: > > On May 26, 2013, at 09:47 , Noah Slater <[email protected]> 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 <[email protected]> wrote: > > > >> > >> 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 > >> > >> > > > > > > -- > > NS > > -- NS
