On Thu, Feb 19, 2009 at 4:12 PM, chromatic <[email protected]> wrote: > On Thursday 19 February 2009 12:57:10 Will Coleda wrote: > >> > For example, we'll release a new version of Parrot on 17 March. It'll >> > probably be 1.0. If we completely fail to provide the ability to build >> > dynops and dynpmcs from an installed Parrot by that release date, we >> > *may* not release that version as 1.0, because it's a blocker. >> >> So, the dated milestone releases are NOT purely date based. Now I'm >> very confused, unless this is a special case for 1.0.[1] > > We don't have any blockers for 1.5, so I'm willing to say that this is a > special case for 1.0. Of course, we haven't gone through a detailed planning > session for much beyond 1.5, so who knows? > >> Why should anything block 1.5? It seems to follow from your arguments >> that there can be no such thing as a blocker for a release. The number >> will increase monotonically; the numbers every six months are special >> only because they assure users we won't remove something they were >> looking for. No? > > That's how I see them, yes. We're not going to hold a feature we've planned > to be in 1.5 if we get it done the day on 18 March. We're also not going to > make a new stable release then either. We release a new stable version of our > software on the third Tuesday of every month. > >> > The date-based numbering scheme was my attempt to do so. >> Ok, but we don't have that now. So we have to come up with an attempt >> here. Here's mine: make the milestone releases every six months be >> 1.0, 2.0, 3.0, and have the monthly releases be 1.1, 1.2, 1.3 , etc. > > Why? Why such a focus on version numbers? Who *cares* what a version number > is, as long as you can tell unambiguously that one release is newer than > another release? > > Why have we spent such a huge amount of time today arguing over real numbers?
Because the plan as was discussed didn't provide a way to number things and be consistent. I don't care HOW we're consistent as long as we are. Don't think of it as bikeshedding so much as making sure the local hardware store sells paint. I see they do now. Excellent. I will go purchase a gallon of their finest. I'm just trying to understand what the plan is. I think I do now, and it seems vaguely reasonable. Thank you for explaining your position. > We're not mathematicians. We're not theologians. We're not arguing over > Planck numbers or fractals or the limitation of human knowledge and > measurement. We're just releasing software, one new version every month. > > Why does it have to be ANY more complicated than "n + 1 is newer than n"? > > (Before anyone responds and says "Deprecation deadlines!" we can just as > easily remove version numbers from deprecation notices and say "Removed no > sooner than March 2010" or whenever.) > >> I was exaggerating for effect. If 2.0 is only bugfixes compared to 1.0 >> (or 1.5), your average parrot consumer will be confused sans >> documentation. > > Why? 2.0 is newer than 1.0 or 1.5. > >> These are all good questions which point to me patching the support >> policy docs so at least I am unconfused by the plan, at least now that >> I vaguely understand it. I'm not saying I don't like the plan. > > Please do patch the docs where they're confusing. We need to point people to > those docs early and frequently, especially to set their expectations for > deprecations and free support. > > -- c > I'll give anyone else who was a PDS a day or few to confuse me more, and then update the docs. -- Will "Coke" Coleda _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
