Disclaimer: I've been following Parrot for quite some time now but because of several reasons totally irrelevant here I haven't been able to contribute as much as I wanted. Actually I think I was close to be a Parrot commiter but right now I'm happy that my application is on hold as I wouldn't consider me as a reliable contributor. Also you will see that I use 'we' a lot, I guess it's just my subconscious telling me to get back to Parrot. Anyway with that said and in accordance of chromatic's law on "Opinions of Non-Contributors" feel free to ignore this post entirely.
There's been a heated debate recently in the Parrot community about the post-1.0 release naming scheme and what each release should mean. Normally I wouldn't really care about it as I usually think that people smarter than me will figure this out better than I can do. However while reviewing the commits log recently I have the feeling that some active developers spend more and more time arguing, get tired of it and as a result become... well, less active.
I wouldn't dare to claim that this is the silver bullet to resolve everyone's problem. This is just my humble contribution to trying to find a middle ground to please if not everybody at least a large majority of people. Also, I'd like to apologize in advance for my awful use of the English language.
Just to get that out of the way, what I don't like :
- noun-based versioning. "Hamm", "Potato", "Slink"? (Ubuntu seems to do better here, but what's after "Zonky Zebra"?)
- odd/even numbering. Segregation against odd numbers is unacceptable.
Here's what I like :
- major bump for API breakage. In my opinion when moving from 1.x to 2.x, you are clearly warned that what used to work may break.
- minor bump for improvements and your regular bug fixes. Same here, moving from 1.5 to 1.6 says "Hey, it's pretty much the same, but better."
- sub-minor bumps for security or important regression fixes : I think this makes sense if the previous rules are applied. If you know that A.x to A.y is the regular update schedule, having a A.x.1 showing up in the distfiles downloads will probably makes you think "oh, there was a hinky with A.x, I should probably get the .1 update."
How could that fit in Parrot's development?
Well, I'm not quite sure but here are some personal thoughts (more like questions actually, in the line of "What if Parrot was doing this, or that... ?") :
What about two development branches : HEAD and STABLE (more on the nomenclature later). STABLE meaning "we won't break anything, you are guaranteed (unless we screwed up somewhere) that any working code for a STABLE branch will still work no matter how many releases we do in that given branch" while HEAD being "We're adding crazy new sexy features, you can start to use them if you want but as it is a WIP we may change it whenever we please. You've been warned." At some point, HEAD becomes STABLE, and STABLE is either deprecated or kept for a few months only for security upgrades. We also can keep the monthly release schedule for STABLE with minor bumps while offering monthly SNAPSHOTs of the HEAD branch.
The Cons :
The most obvious one is that two branches will mean twice as much of work. Well, not exactly twice but bug fixes and non-API-breaking improvements will have to be added in both branches. For a (too few already) volunteer-driven project like Parrot this most certainly is a big No-no! That said, considering that the STABLE branch won't get earth-shattering changes it will probably consume less energy than HEAD.
Selling the SNAPSHOTs/STABLE to the users. The STABLE and SNAPSHOTs are probably a bad choice of wording. STABLE for one will probably make people think that anything else is not going to work and will sneakily coredump on you every time you're not looking. SNAPSHOTs makes you think "we're not quite there yet" and this is wrong as I can't remember when there last was a Parrot release that didn't pass all its tests on my boxes (and ask around, I have some very capricious boxes).
All the projects depending on Parrot are now victims of this release plan. Say one project needs a feature added in the first monthly snapshot of HEAD, I doubt they can advertise in the release notes "You need at least the first SNAPSHOT the of 2-HEAD branch Parrot to make this work." Well, they can but I bet they won't.
The Pros:
Flexibility for one. Parrot currently is a fast-moving target. You can make the HEAD-to-STABLE switches on a time-based manner (like every six months) but at a later point when everything will be in place and the urges to break oh-what-did-we-think-about-N-years-ago crufty code will be long forgotten we can chose to switch on a feature-based roadmap.
Two "releases" a month. Provided that users can grasp the the concept of everything we release is rock-solid and tests-passing, they'll get their fix of new shinies every month as well as a less adventurous upgrade but yet improved release.
No magic number. Unless I misunderstood the idea behind "magic numbers" ( X.y is a deprecation if y%6 = 0 and/or the release month is... otherwise it's bug fix and improvements ), I like the idea to have major-bumps for deprecation and minor-bumps for improvements. And personally I don't care if 'Good for production' is at 2.0 or 5.0.
So, to summarize:
HEAD: 5.a 5.b 5.c 5.d 5.e 6.a ...
STABLE: 4.0 4.1 4.2 4.3 4.3.1 4.4 5.0 ...
END_OF_LIFE: 3.8 - - - 3.8.1 - 4.5 ...
^ ^
sec-fix deprecation
Well, I guess that's it. It's far from perfect. People may not like it. I'm just saying that I'd happily live with it. I hope there's some meat in there that people will find useful.
Thank you for your attention.
--
G.
The most obvious one is that two branches will mean twice as much of work.
That's its fatal flaw. This strategy hasn't worked for Perl 5 for years; I'm not sure why anyone would think it would work for Parrot now.
I want Parrot releases to be so dull, boring, and predictable that there's never any question of whether you should upgrade. Anything special we have to explain works against that goal. (I realize that some people still think upgrades should be painful, but there's no way to help them.)
