Marvin Humphrey wrote on 3/9/10 10:57 PM: > > This isn't a perfect solution, but I think it's at least a satisfactory way to > resolve the current situation. The "stable" branch has been highly stable for > a long time, but those users were still warned by that prominent ALPHA warning > at the top of the docs -- expecting them to make a one-time switch is > acceptable.
I've been delaying in my response to this because (a) it took me awhile to grok the idea, and (b) I've been trying to play through scenarios based on my desire to keep my KS extension modules happy. I *think* I understand the idea. I.e., KinoSearch 0.1x becomes KinoSearch1, KinoSearch 0.3x becomes KinoSearch3, etc. Is that right? I don't have the same personal commitment to back compat for my own modules, so I'll happy continue pegging them to whatever the latest CPAN version of KinoSearch is. Until, of course, I hear from users of my module who can't/won't upgrade their KS installs and then I'm fine with a back-fork under a different namespace, as you're describing (I think). > > Does anybody know if any other projects have ever used a similar release > strategy? I don't. Usually a project with abandons earlier user base by changing APIs at major releases levels, or does gymnastics to provide eternal backwards compat (the latter seems to be what Perl does). -- Peter Karman . http://peknet.com/ . [email protected]
