Front page | perl.perl5.porters |
Postings from October 2009
Increasing the version number before or after the release? (was Re: identifying devel releases) I tried to follow the 'identifying devel releases' thread but there are some things that confuse me and that I fail to understand/fail to see how they are different. Rather then continuing that thread (and the confusion) I'm going to try a different approach to find what approach is more suitable for Perl. To do this I want to limit the scope of the replies (if any) on this message. What I want to read is arguments in favor or against increasing the version number right before/after a release but I want to limit the arguments. Things I do not want to hear: - Project X increases the number right before/after a release. This argument is (IMHO) not very useful... Perl is not Project X. If you want to use this argument then I suggest you try to find out *why* Project X does it that way and use that reason as argument (if the reason also applies to Perl) - X is easy to do with git/VCS or Y is manual work. When the 'problem' is looked at it from this point of view then it is being looked at from the implementation side and not from the design side. IMHO this issue is important enough to properly think about the design (read: 'what we want') before we think about the implementation (read: 'what can we do'). What I want to read: arguments based on design and not implementation. The goal is clear: perl -V should clearly indicate what version it is: - is it an official release? - is it a release candidate? - is it a perl build from a snapshot/commit? As in, X commits after an official release The question: what version number is used X commits after an official release? - Is the new version number used (=> increasing the version number right after a release) - Is the old version number used (=> increasing the version number right before a release) Arguments/Assumption: - A change in the version number creates bugs. When the version number is changed early (right after the release) then it is constantly tested (more smokes) and bugs with the new version number (in the core and on CPAN) are detected sooner. When these bugs are detected then *anyone* can try to fix them. When the version number is changed later (right before the release) then it gets very little testing and any bugs that are created due to the change in the version number will (most likely) block the release. At that moment it is very likely that the pumpking will need to investigate/diagnoze/reproduce and fix every bug. Summary: the later it is changed the more likely it becomes that it will block the release and the more work it creates for the pumpking. - Unpossible to know in what version a commit is included. Assumption: * 5.6.6 is the latest offical release * when a commit happens after 5.6.6 then it is not possible to know in what version it will be included (it might be reverted 10 commits later) Some names I've seen in the thread: * 5.6.7-devel-gdeadbeef Is it a development version of 5.6.6 or 5.6.7 or 5.6.8? * 5.6.7-inprogress-gdeadbeef Is 5.6.7 in progress or is 5.6.8 in progress? * 5.6.6-gdeadbeef This represent where the commit is positioned (that is somewhere after the 5.6.6 release). Question: what with the .0 releases? The current situation: 5.11.0-gdeadbeef represents commits that happend before the release of 5.11.0 and it represents commit after the release of 5.11.0. How should the commits before the release of 5.11.0 identify themself? 5.9.5-gdeadbeef? 5.10.0-gdeadbeef? 5.10.1-gdeadbeef? ...? Summary: What should the name represent? The name is critical and shold be documented in all relevant places (perhaps also in perl -V) - ??? Best regards, BramThread Next