I’m rethinking doing an 0.14.1 release – but hear me out. I’ve been doing a decent amount of work on the code lately, and what started out as a bug fix release has started evolving into a new feature release as well. My take is that sub releases should be bug fixes only – but I’ve added a new dep (Shell::EnvImporter), changed some of the functionality, plus fixed some outstanding (for time, not glamour) bugs, which sort of makes me think that the next release should be 0.15 – which means it will be pushed back a little bit further than I expected (cab: I think I have an elegant, simple solution to the config file addition ;). On the short list of things I’d like to do (in case evolution eats my todo list or something):
* Config file – exploiting Shell::EnvImporter a bit more, I’m thinking of a simple make.conf replica file with some additional option flags, but mostly as an override to make.conf. Not sure how this will work for some of the portage stuff when it comes to actual emerge time. I’d also like to consider an “if sudo” block so that ebuilds can be generated as a user, and root is only needed for the final emerge.
* Code cleaning – personal gripe with a beatiful plan gone awry. Want to try and clean up the visual appeal of the code from obj->ref->ref->ref->key to something a bit more readable (and memorable).
And since I’m extending this a little, a few things I want to look at trying to accomplish…
* What to do when $PORTDIR/dev-perl/module is older than the required version?
* What to do when your keywords are arch, but your deps are ~arch
And finally, related to bug 159360, do we need to maintain a master dependency graph so that all generated ebuilds dep at least the same version? Seems rather silly to me for what to me is an obvious portage bug, but in the end I want g-cpan to work (no matter who I have to mow down in the process).