[DBIx-Class-Devel] version numbering scheme

Peter Rabbitson rabbit+dbic at rabbit.us
Mon Feb 25 10:42:39 GMT 2013


On Mon, Feb 25, 2013 at 10:08:12AM -0000, Jess Robinson wrote:
> 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)

See the changeset summary in 
http://lists.scsys.co.uk/pipermail/dbix-class/2013-February/011109.html 
In particular "multiple has-many" and "partial prefetch",

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

There actually isn't CPAN consensus, even among the highly visible
dists.

> particular one? Ideally the Roadmap should list an idea of the
> coming version numbers to go with the coming plans..

This is the main part of your message I want to reply to. In my opinion 
a roadmap for a project like DBIC is not feasible. The complexity brings 
in an explosion of "avenues to explore". Hence while there are 
*individual* roadmaps from different contributors, these roads do not 
all lead to Rome or to DBIC with feature X or anything like that. On the 
contrary most of these roads lead in opposite directions. Furthermore 
there is a massive imbalance between the ineterests of the active 
contributors and the interests of the inactive contributors (i.e. I do 
not see myself working on adding shortcuts for "common cases", yet I 
hear about them all the time, which makes me think they are popular to 
someone).

For a different wording of this viewpoint see: 
http://www.nntp.perl.org/group/perl.perl5.porters/2013/02/msg198442.html

Cheers




More information about the DBIx-Class-Devel mailing list