[DBIx-Class-Devel] version numbering scheme

[Jess Robinson]

On Mon, 25 Feb 2013 09:24:44 -0000, Peter Rabbitson  
<rabbit+dbic at rabbit.us> wrote:

> On Mon, Feb 25, 2013 at 09:54:19AM +0100, Alexander Hartmaier wrote:
>> Hi list,
>> before the constructor rewrite, which is currently known as 0.08241,  
>> gets
>> released, I'd like to discuss the version numbering scheme of DBIC.
>> Imho we are much too shy in bumping the version number visually  
>> significant
>> when new features get released.
>> DBIC should be at least at version 1.x since the early 0.08 days, since
>> then many great things (quoting, datetime_setup, ...) have happened  
>> without
>> a major version bump.
>> I'd like to define how the DBIC version number is constructed and a  
>> policy
>> when which part of the version number gets bumped.

It would be a good idea to have such a definition, imo.

>> I propose the following version number scheme: $major.$minor.$bugfix
>> which translates to $major.$three-digits-minor$three-digits-bugfix in
>> floating point version number style.
>>
>> Bumping rules:
>> - $major: large new or changed feature gets merged. If the constructor
>> rewrite falls into this categoriy should be discussed (see below).
>> - $minor: on small changes
>> - $bugfix: for bugfixes only, 0.08206 falls into that category, it has  
>> no
>> 'New Features / Changes' section in the Changes file.
>>
>> Furthermore I'd like to see a 1.000000 version either before the
>> constructor rewrite gets released as 2.000000 or the constructor rewrite
>> being released as 1.000000 if we (read ribasushi who wrote it) is  
>> feeling
>> confident that it won't cause some larger breakage.
>>
>> What's your opinion on that?

I think we should have had a 1.0 ages ago. 1.0 is for a stable, mature,  
well used module, in my opinion. It tells users we're not experimenting  
with the whole system, we're not changing APIs from under them.

I think the major version should only advance for features which either  
change existing API, or add major new *visible* functionality (the  
constructor rewrite doesn't sound like its visible, not that I've looked  
yet)

Minor versions for other improvements: speed improvements, major change of  
internals, etc.

> My personal opinion is that 1.0 is for products that are entering
> "support mode", not for products that are under rapid-ish development.
> Given what is happening in the world lately (e.g. Firefox) it makes me
> even more alergic to random version bumps.

Disagree, see above. IMO what matters is what CPAN dists do in general, as  
users will have expectations. Catalyst gets it right I think.

> To summarize - I am opposed to 1.0 until many more of the new features
> have landed, and am opposed to all the reasoning Abraxxa gave above.

That could be said forever and ever.. we've *had* many new features over  
the years, why keep waiting until that illusive undefined particular one?  
Ideally the Roadmap should list an idea of the coming version numbers to  
go with the coming plans..

> On the other hand - my voice is just one voice - if this is what the
> rest of the dev want I will just have to buy more allergy medicine.

Ditto,

Jess