Re: couchdb stable
On Tue, 18 May 2010, Sam Bisbee wrote:
> > That's not okay. The promise we make when we release a stable version of
> > any of our packages is not the same than any promise upstream can make.
>
> Sorry, I'm confused as to the point you're making here. Could you please
> rephrase?
When a maintainer lets it package reach a stable release, he makes the
implicit promise "we will support _this version_ for 2-3 years" and this
promise should hold true whatever upstream is saying. Of course, the
upstream position should be taken into account when he decides whether
it's realistic or not to support that version for 2-3 years.
> > > I'm not asking for constant pushes to stable or anything, but I'm considering
> > > stability, security fixes, and the usefulness of stable - if people don't use
> > > stable because of "no" features and it not being, well, stable, then why do we
> > > have it?
> >
> > Why was it packaged in unstable and not in experimental at that time then?
> > Or why was no RC bug opened to avoid it going into stable?
>
> You're asking questions about things before my time. However, I think you might
> be misunderstanding the point I was making there: it's not that 0.8.0 was out
> of date back in 2008 (it was released by upstream then) and shouldn't have gone
> to stable, but it is out of date now.
It's not a matter of out-of-date or not. It's a matter of "is this
supportable for 2-3 years?".
Anyway, forget your idea to freshen up stable. The only way to freshen up
stable is to make backports available to users. That way they can choose
to use a newer version and it's not imposed to those who are happily using
the stable version and who would be surprised by an unexpected change.
Cheers,
--
Raphaël Hertzog
Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/
My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/
Reply to: