[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