Sure, just look at Hadoop. But I'm not hung up on the port/starboard numbering scheme either. Either 0.6.1 or 0.7 work for me.

On 2/22/12 11:46 AM, Jake Mannix wrote:
On Wed, Feb 22, 2012 at 10:40 AM, Dmitriy Lyubimov<dlie...@gmail.com>wrote:

I guess i still prefer 0.6.1 for maintenance releases (esp. given the
short cycle).

Another supporting argument against even/odd scheme is that this
naming doesn't really reflect the actual level of product maturity
(e.g. 1.0 this way ends being a "new-feature-being-unstable-beta"?
whereas in reality 1.0 is being read as "wow, it's one rock-solid
production grade " by most conventions out there.

no, 0.10, 0.11, 0.12 can still exist, and we don't get to 1.0 until
we wish to, and as a major version has been bumped, has
different connotations to the minor number convention.

   -jake


-d

On Wed, Feb 22, 2012 at 7:46 AM, Geek Gamer<geek4...@gmail.com>  wrote:
Odd / Even releases for cleanup maintenance vs feature additions looks
great.
On Wed, Feb 22, 2012 at 8:58 PM, John Conwell<j...@iamjohn.me>  wrote:
I think it sounds like a good idea.

On Wed, Feb 22, 2012 at 4:24 AM, Jake Mannix<jake.man...@gmail.com>
wrote:
On recent threads on the dev@ list, and discussions off-list, it's
pretty
clear that we need to have "cleanup" be a priority for the next
release.
How about this for a formal proposal:


   -   The 0.7 release will have issues (both new and on JIRA) be
primarily
   focused on bugfixes / cleanup / API-refactoring / etc, with "new
   feature"-work only coming in when it's been pushed off for too long,
and
is
   close to completion.
   -   All non-"cleanup" items will still be tracked and discussed, but
   JIRA-tickets related to them will be marked 0.8 at the earliest, and
they
   won't be committed until 0.7 goes out.


If we're able to wrap this release up cleanly and get quickly moving
on to
new features again, maybe we can try this on a more regular basis, with
even releases being feature-work, and odd releases being maintenance
and
cleanup (and hopefully having much shorter turnaround time).

What say ye?

  -jake



--

Thanks,
John C

Reply via email to