Hendrik Boom <[EMAIL PROTECTED]> writes: > On Sun, Jul 10, 2005 at 11:23:10AM -0400, Johan Kullstam wrote: > > Mark Fletcher <[EMAIL PROTECTED]> writes: > > > > > On Sunday 10 July 2005 21:55, Joris Huizer wrote: > > > > Johan Kullstam wrote: > > > > > Let me see if I understand you correctly. Your > > > > > reason for having the ambiguity of wether to call > > > > > it 3.2 or 4.0 is just to keep people from assigning > > > > > etch a number? > > > > > > > > I think this is quite logical, as there is some > > > > structure in those numbers - 4.0 means a big leap, > > > > 3.2 means "smaller " change; nobody can tell right > > > > now how big the step is from sarge to etch, as it's > > > > development has just started > > > > ofcourse, it's just up to the debian development team > > > > to decide wether the changes are big enough to call > > > > it 4.0 (anyone know why sarge became 3.1?) > > > > > > > > just some thoughts > > > > > > > > Joris > > > > > > I'd add that it's not deliberate ambiguity as a means to > > > any particular end, so much as it not being an > > > appropriate stage of the development of etch for the > > > decision to be made if a major or minor version upgrade > > > is appropriate. This does matter; this list wouldn't > > > take long to hear from a whole tribe of people with > > > nothing better to do than complain about unimportant > > > things if they decided it was to be 3.2 now and then it > > > turned out that the changes were massive and the > > > upgrade path difficult... likewise if they decided 4.0 > > > now and then it turned out the changes were small and > > > relatively minor . > > > > Are people really going to look at the version number and say, "I've > > got sarge now and since new number is 3.2 i'll upgrade but if it were > > 4.0 i'd sit still?" Have people done this in the past? > > > > Releases come every 3-4 years so why not let the release notes explain > > the changes. A version number might make sense for automated things > > where cron downloads and installs a minor increment but not major > > one. This is so seldom that manual intervention isn't too much to ask > > for. > > > > Since the difference is subtle, why have the distinction? Why not use > > next release is 4.0 and the one after that 5.0 and so on *no matter > > how small the update*? > > Well, no matter whether the etch release next year or later is going to > be a big or a little upgrade, etch isn't stable yet, and so if > it's going to be 4.0 or 3.2 or 3.1415 or whatever, the numbers > (if any) for what we have now are going to have to be less than that. > So for the time being, 4.0 is probably inappropriate as a version > number.
I don't see why 4 is inappropriate. 4 has been the successor to 3 for a few thousand years. I don't think that will change in the next decade. > 3.2 might be OK. 3.1.9 is probably too close to numbers for sarge > with security upgrades. But still, I ask, why the minor and major numbers? Does this help anyone in the least? Others ask why a number at all. That's a good question. > But does it even need a version number right now? Or will it need a version number ever? Seriously, what is the point? Etch.0 etch.1 &c might be ok. Call it etch.0 while in testing. Then etch.1 at release. Roll-up upgrades are etch.2 etch.3 &c. > If it were a package, > aptitude and its friends would have to know it. But it isn't. > Or is that one of the big changes we're going to see? That the entire > distribution becomes a package? > > -- hendrik > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- Johan KULLSTAM -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
