Yes, you're right that even when releasing a single module a new parent should be released. So that using the dependency management of the latest released parent ensures the latest released versions of all modules.
Cheers, Reto On Mon, Mar 26, 2012 at 2:53 PM, Daniel Spicar <[email protected]>wrote: > On 26 March 2012 13:44, Reto Bachmann-Gmür <[email protected]> wrote: > > > On Mon, Mar 26, 2012 at 11:21 AM, Daniel Spicar > > <[email protected]>wrote: > > > > > On 24 March 2012 15:57, Reto Bachmann-Gmür <[email protected]> wrote: > > > > > > > On Mon, Mar 19, 2012 at 2:54 PM, Fabian Christ < > > > > [email protected] > > > > > wrote: > > > > > > > > > Hi, > > > > > > > > > > Am 19. März 2012 14:36 schrieb Daniel Spicar <[email protected]>: > > > > > > But how do you handle maven version numbers? In order for this to > > > make > > > > > > sense I think you handle versions manually per module. That means > > > > after a > > > > > > release you do not make the module depend on the latest SNAPSHOT > > > > versions > > > > > > of all its dependencies but rather you stick with the oldest > > release > > > > > > > > > I tink you mean newest release > > > > > > > > I mean the the "first" release it needs to depend on. Not the newest > > > release out. E.g. If a API consumer bundle depends on version 1.1.1 of > > the > > > API, it should always depend on 1.1.1 as long as it doesn't need to > > depend > > > on a newer version. No matter if meanwhile version 1.2.5 of the API is > > > out. > > > > > > > For bundles, i.e in the OSGi environment you're right in principle. In > > practice however I think that the effort to check which is the oldest > > version that suffices and ensure this with tests might often be a too big > > effort. > > > > For maven artifacts I would default to the newest release, pure api > > artifacts are seldom and even there the newer version might bring > > advantages, such as a better documentation. > > > > Given the process I outlined the idea was that you don't need to care about > looking for specific versions. This situation will evolve naturally because > you do not touch bundles that you don't need to worry about. However the > effort will be on the developer to apply OSGi semantic versioning > correctly. Then, if you overlook something, you will see it at runtime > because dependencies can not be resolved. But this would be problematic > when OSGi versioning is not used. > > And the latest documentation would be available because the launcher > project would use the latest versions. At runtime, the "old" dependency > would only influence the declared version requirement, not the > implementation. But it would allow the bundle to run with older > requirements too. > > > > > > > > > > > > > > version you depended on and only increment to the next SNAPSHOT > > when > > > > you > > > > > > require new features or some other reason may require an update > > (e.g. > > > > > major > > > > > > version change). > > > > > > > > > > I think this is the way to go. Currently, we have the same issue in > > > > > Stanbol and I am thinking about doing it exactly this way. > > > > > > > > > > > > > > > Why not release a fresh parent whenever a set of modules is released? > All > > > > > > modules in trunk should then be updated to use the new parent. The > > effect > > > > > > is the same: a module depends only on relased components unless there > is > > > > reason to depend on snapshot in which case the modules will be > released > > > > together. I think the maven versions plugin comes in very handy here. > > > > > > > > > > Given which release process? > > > > No, moving the parent project in a subdirectory and having a reactor > build > > pom where currently the paren pom is. > > > > > > > In the current release process the parent has > > > lots of SNAPSHOT versions in its dependency management because all > > bundles > > > are automatically snapshotized after a release. > > > > I think that only modules that are part of the release are snapshotized. > > > > Well currently, in trunk, everything (or at least almost) is a snapshot > version. So next time someone tries to release just one module the problem > appears and the situation won't change if the released module is > snapshotized after release (because still the same amount of modules will > all be snapshot versions). The problem lies in central dependency > management creating unneeded "dependencies" between everything managed in > dependency management. These dependencies don't apply at runtime > (especially because we do not use OSGi versioning) but affect the source > release of the module. > > > > > > > > So in order to be > > > consistent you can either revert the versions of unchanged/unreleased > > > bundles in dep. management to the last release version when you > release a > > > new parent, and put it back to the latest snapshot version after > release > > > (plus update each module's pom to depend on the latest parent), or you > > have > > > to release all bundles and snapshotize them again, causing a version > jump > > > even without changes. But it seems unnecessary to have to meddle with > > poms > > > of bundles that did not change simply because an the implementation in > an > > > independent bundle changed. > > > > > > > A module that isn't part of the release isn't touched. It might have an > old > > snapshot parent as parent. When only a single project is to be released > > then it is enough to update the parent to the latests released version. > If > > multiple modules have to be changed and released then you must manually > > make sure that the parent has snapshot versions of the artifacts to be > > relased while the other dependencies in dependency-management have to > > point to the latest release, this is best done in an svn branch. > > > > Cheers, > > Reto > > > > You mean, that if I want to release a new version of (e.g.) the user > manager. I would make it depend on parent 0.2 (when it is currently on > 0.3-SNAPSHOT in trunk)? Then the source release will be really awkward > because dependency management of parent 0.2 says that user management > version is 0.2 (I think) but you just released the code base of 0.3 (I > think). If something depends on user manager and it needs the new version > it needs to declare it manually. Then you dilute the whole idea of central > dependency management. The same for projects that use clerezza, they would > need to analyze what we changed and add manual dependency declaration if > they want to use the new release of user manager because from dependency > management they inherit version 0.2. The alternative is to release a new > parent with new dependency management and revert all unrelated modules to > the latest release (I think you suggested that too). > > Before I was under the impression that currently we do it differently and > we do not allow dependencies on old parents. Nevertheless you will not get > rid of manually making sure that dependencies add up in any of those cases. > > But in general this is part of the process I suggested. Unrelated bundles > should be able to depend on the version they need, not be forced to depend > on the latest version even when nothing changed for that bundle. Some of > the additional specifics arise from the introduction of OSGi package > versioning and its semantics. > > Best, > Daniel >
