Hi, 2013/2/21 Daniel Spicar <daniel.spi...@gmail.com>: > I believe > Stanbol wanted to move to a similar versioning policy back then as well. I > did not follow up on how they implemented it. Maybe we can get some > inspiration there though.
yes in Stanbol we are trying to follow the approach that we release independent components. It is basically the approach described by Daniel and was also influenced by Sling. I have myself spent a lot of time figuring out what the best process could be. I can confirm that the release plugin sounds like a great tool but it is based on a different release process in mind. Also my feeling is that it has its problems with complex multi module structures. For example, the release plugin has this process: - Update everything to release versions - Tag - Update everything to dev versions But the Apache release process is different - Update everything to release versions - Tag - Stage the release - Vote - Only on success publish the release and then update dev versions or use the released stable versions The problem is that all the tools to update and manage dependency versions have their problems. I am really missing tool support here. There is the versions plugin but after many experiments it also has problems with multi module project and parent POMs at different hierarchy levels. And this is only the Maven side. With OSGi we have a second layer of dependency management which controls the runtime deps. For this layer, there is absolutely no helping tool support. So, practically cutting a release is not that easy and somewhere in the process it is often inevitable to forget to update some dep on Maven and/or OSGi level. I am really interested in a working solution but I can not offer one at the moment. Currently, I am also investigating the technique of using release branches. This gives a little more freedom during the process and people can work on the trunk without interfering with the release in progress. Best, - Fabian -- Fabian http://twitter.com/fctwitt
