Lasse Vågsæther Karlsen wrote: > While Microsoft and other big software vendors might have a roadmap > that ties you very tightly in with their budget, and also changes that > roadmap from time to time which breaks your current software, a lot of > open source projects have no roadmap at all. > > This means that a .x.y.2 upgrade might very well kill your software in > the same way a 6-7 upgrade with VB might.
I think this explanation confuses the term roadmap with general release discipline. A lot of open source projects are, well, open about things like API stability and will label their stuff as "alpha" if things are going to change frequently - one complaint heard relatively often is that many open source projects are reluctant to put out a 1.0 release because they don't consider their work to be finished. Meanwhile, many open source projects do try and preserve consistency between micro-releases, with any inconsistency being a fault that should be raised with the maintainers - such faults being a phenomenon not limited to open source software, either. > The biggest reason for this, as far as I can tell, is that open source > projects are very > much built to integrate with other projects, simply because the source is > available and it's thus far easier to integrate them, but that also > means that unless you upgrade two integrated projects at the same time, > you risk an upgrade in one breaking the other. I'm not sure whether source availability is really the problem here. I've experienced micro-release breakage and it was due to the integration of lots of different libraries, many of which were upgraded in the process of making the new micro-release of the software in question, but with some of the more egregious breakage coming about because in some micro-update of one of the libraries, the author decided to radically change the available features of that library. Since this was all Java-based, source availability really wasn't a factor (these were all .jar files, after all); the problem could be boiled down to good old release discipline: if one of your dependencies plays fast and loose with API stability, expect some users to get caught out. If package maintainers make transitions of their software from release 2.4.2 to release 2.4.3 involve significant rewrites of your own application, my advice involves either avoiding such packages from the beginning or, if it's too late, considering what would be necessary to maintain/subvert acceptably stable versions of them. > I think a main point in a lot of projects is that unless you have to > upgrade, don't. That way you can avoid a lot of problems by default. This is good advice! The big difference between open source and Microsoft, however, is that you can feasibly choose not to upgrade to the next bloated/misguided release of some software and yet attempt to roll in all the security updates and useful enhancements whose absence would otherwise expose your applications to misuse or obsolescence. Either path can involve a lot of hard work, but at least you get the choice with open source software. Paul -- http://mail.python.org/mailman/listinfo/python-list