[Dbix-class] Path from here towards actually getting a release out

Matt S Trout mst at shadowcat.co.uk
Thu Oct 5 03:04:04 GMT 2017

(obviously, "fix any bugs we find while testing" should be taken as read)

I have a few areas of concern wrt the changes made since last release:

1) The sanitychecker code is going to point out a lot of things that were
only ever accidentally working - but many of those things may continue to
accidentally work, and if it barfs valid-but-numerous warnings all over
people's log files that may discourage people upgrading who would, on the
whole, be better upgrading anyway (and while most of the changes to the
internals were in prior releases, people have this tendency not to upgrade
as often as I would ideally like). Note: this may be me being pointlessly
paranoid, but I'd like some experience reports from users to try and gauge
it by before I file it under "we should just tell them to stop worrying and
learn to love the sanity checker".

2) A different class of 'accidentally working' requires the addition of
attributes to methods, and I suspect that, for people who (a) are using
method modifiers (b) are using anything else that doesn't set attributes
normally (c) just hate attributes, we should provide an alternative interface
that lets them do it a different way. This may be as simple as documenting
that you're allowed to call attributes::import instead, though since I've got
at least one foot in category (c) above I think I'd prefer something that
isn't *dependent* on the attributes system and merely allows the use of
attributes as one possible interface to it.

3) Check through outstanding branches for things that are sufficiently
low impact and/or high value that didn't make it into master but should
probably do so by release time.

4) Check RT for bugs that have come up during our unfortunate hiatus that
are important enough we should consider rolling fixes for them into the

5) Anything else the list membership can think of that I haven't.

These all seem like things we can discuss while the devrel's soaking - though
for (1) and (2) I guess people are going to want to actually play with the
devrel, and everybody's opinions being basically 'mu' until they start doing
so is fine by me.

But, roughly, what I'm thinking is our process should be:

* another devrel that at least starts to cover 3/4
* ask people who're adventurous to try that one and have opinions about 1/2
* decide what if anything should be done about 1/2
* roll a 'this might become an RC' devrel with the results of 1-4
* see what everybody thinks of that one
* plan path towards a stable release

Of course, category 5 could easily result in comments that make this
process need a complete redo.

Thoughts from the list on the above would be very welcome, or if your
thought is "looks basically reasonable" then a +1 would be nice (once there's
3 or 4 such replies there's no need to add to them, but I'd at least like to
know "some people think it looks basically reasonable" if that's the case).

Matt S Trout - Shadowcat Systems - Perl consulting with a commit bit and a clue

http://shadowcat.co.uk/blog/matt-s-trout/   http://twitter.com/shadowcat_mst/

Email me now on mst (at) shadowcat.co.uk and let's chat about how our CPAN
commercial support, training and consultancy packages could help your team.

More information about the DBIx-Class mailing list