On 1 February 2011 17:37, zoe slattery <[email protected]> wrote: > On 01/02/2011 17:03, Guillaume Nodet wrote: >> >> As I said in my previous mail, one possibility would be to split the >> release cycle and artifact versioning scheme from the osgi package >> versioning scheme. >> Which we already do to some degree when we release blueprint-bundle >> which contain the blueprint-api in version 1.0 and the implementation >> in version 0.3. >> > I think this is worth looking into. >> >> Honestly, given the hassle of releasing things, I think a single trunk >> + single release cycle is the easiest way to go. I think if we have >> a simple release process, we could release things more often and maybe >> maintain branches. I don't really see any problem in having >> blueprint-cm-0.4.0 being the same as blueprint-cm-0.4.1. But if it >> takes 2 days to one person to do a release, less people will volunteer >> to do those, which is imho worse, as we won't deliver fixes to our >> users. > > The release process as it stands is actually very simple - and - though I > should probably not say it myself - it is well documented.
FWIW I think it's good :-) > It took me a little time to do 0.3 but I had/chose to make fixes to a lot of > poms. if we'd had smaller more frequent releases it would have been done bit-by-bit and not taken a lot of time to do all in one go. > > I worry a lot about making the development process more complex. The reason > that I was fixing poms for 0.3 is that one or two people didn't > understand the pom construction, also there were a few licences to fix. > Without these issues (which are completely avoidable > by putting comments in the poms and running rat in the build) it would > really be quite fast to release the whole of Aries. Take application 0.2.1 as an example - that happened very quickly. What takes the time is the 72 hours for the vote but that's not 72 hours of working time, just elapsed time. Also, the need for 3 PMC members to vote (and hence have checked the release) - well if it's small it'll be quicker to check. > > Making the development process complex will make it harder to remember - and > will likely make releasing harder because people won't remember > the development process and the release manager will then have to fix it. > Also, if it's so hard for us to think of what the process should be, isn't > that an indication that we are heading for something too complex? > > Zoe > > > >> On Tue, Feb 1, 2011 at 16:22, Jeremy Hughes<[email protected]> wrote: >>> >>> On 1 February 2011 14:54, Guillaume Nodet<[email protected]> wrote: >>>> >>>> This is very different from what we have I think, as gogo's root pom >>>> isn't used at all. >>>> Releasing gogo involves releasing each of the maven subproject >>>> independantly afaik. >>>> >>>> The main difference is that all felix releases consists of a *single* >>>> bundle. If we go this way, that would mean that releasing blueprint >>>> only would require 13 releases. Some of those just contain tests, so >>>> that does not make sense to me. From an usability point of view, I >>>> would definitely not go that way. I'd personaly rather go in the >>>> opposite direction and use a single reactor / release for all >>>> components. >>>> >>>> Another consideration is that I think we should tie the release cycle >>>> with the svn layout, i.e. if we want to keep each component with a >>>> separate lifecycle, we should have multiple trunks. That's way >>>> cleaner imho (and much more git friendly btw). >>> >>> Lets discuss the multiple trunks idea a bit ... are you suggesting >>> something like: >>> >>> aries/application/branches >>> aries/application/tags >>> aries/application/trunk >>> aries/blueprint/branches >>> aries/blueprint/tags >>> aries/blueprint/trunk >>> etc >>> >>> We'd still be left with the multiproject issue - release blueprint >>> 0.3.1 for a single fix and all the blueprint bundles are released >>> whether they contain fixes or not. If each child of >>> aries/blueprint/trunk was only a single bundle (they are today, but >>> other top level modules like application would need some changes to >>> fit with this) ... then we could release each of them independently. >>> >>> But ... every time we release a bundle in blueprint we need to release >>> the 'uber' bundle - built from blueprint/blueprint-bundle. So, for >>> example, we would get to a situation where we release a fix to >>> blueprint-core @ 0.3.1 (and hence uber blueprint 0.3.1). Then >>> blueprint-cm needs a fix release - it's next micro number would be >>> 0.3.1 (we'd have to release uber blueprint @ 0.3.2). >>> >>> If blueprint-api then needs to release some additions to an interface, >>> then according to semantic versioning rules, it has broken >>> implementors of the interface, so its minor number goes up (to 0.4) >>> and of course blueprint-core implementing that would need to go up to >>> 0.4, and the uber blueprint bundle would go up to 0.4 too - but other >>> blueprint bundles wouldn't get released and hence stay at 0.3. >>> >>> This is a fairly complex process that we'd need to be careful to get >>> right. >>> >>>> On Tue, Feb 1, 2011 at 15:25, zoe slattery<[email protected]> >>>> wrote: >>>>> >>>>> Hi Felix >>>>> >>>>> I had a look at felix to see if I could work out how you do the >>>>> independent >>>>> releases. I didn't look through absolutely everything but >>>>> I only found two modules that had sub-modules (gogo and http). Of those >>>>> two >>>>> it looks as though the pom structure in gogo might be similar >>>>> to what we need in Aries. Is this a model you would recommend? Or is >>>>> there >>>>> something closer? >>>>> >>>>> Zoe >>>>>> >>>>>> Hi, >>>>>> >>>>>> Am Montag, den 31.01.2011, 15:22 +0100 schrieb Guillaume Nodet: >>>>>>> >>>>>>> Wouldn't that imply that each bundle has its own lifecycle ? >>>>>>> I think a while ago we agreed on having one release per "component", >>>>>>> i.e. blueprint (which includes api + core + cm + ...). >>>>>>> I'm not sure how well this would go if we have blueprint-core >>>>>>> 0.4.0-SNAPSHOT depending on blueprint-api-0.3.0. >>>>>> >>>>>> I bet you won't release blueprint-api as version 0.4.0 if it is the >>>>>> same >>>>>> as 0.3.0, right ? >>>>>> >>>>>> Regards >>>>>> Felix >>>>>> >>>>>>>> From a users point of view, it certainly does not help because all >>>>>>>> the >>>>>>> >>>>>>> maven transitive dependencies are kinda screwed. >>>>>>> >>>>>>> On Mon, Jan 31, 2011 at 15:11, Felix Meschberger<[email protected]> >>>>>>> wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> Am Montag, den 31.01.2011, 13:59 +0000 schrieb Jeremy Hughes: >>>>>>>>>>> >>>>>>>>>>> (c) Where an Aries module depends on other Aries modules, it will >>>>>>>>>>> depend >>>>>>>>>>> on the released versions of the other modules _until_ it requires >>>>>>>>>>> a >>>>>>>>>>> change in the module that it depends on, at which stage it will >>>>>>>>>>> switch >>>>>>>>>>> to a dependency on the development version. >>>>>>>>>>> So for example, Blueprint 0.4-SNAPSHOT will depend on quiesce >>>>>>>>>>> 0.3, >>>>>>>>>>> proxy >>>>>>>>>>> 0.3, testsupport 0.3 and parent 0.3. If blueprint 0.4-SNAPSHOT >>>>>>>>>>> needs >>>>>>>>>>> to >>>>>>>>>>> pick up a change in proxy the blueprint top level pom will need >>>>>>>>>>> to be >>>>>>>>>>> modified to point to proxy 0.4-SNAPSHOT. >>>>>>>>>> >>>>>>>>>> I would assume this means "depends on modified API" and does not >>>>>>>>>> mean >>>>>>>>>> "depends on some bug fixed in the implementation", right ? >>>>>>>>> >>>>>>>>> If you're referring to the semantic meaning attached to moving from >>>>>>>>> 0.3 to 0.4 then I think that would be taking this discussion in a >>>>>>>>> different direction. But that is a good point. Before getting into >>>>>>>>> a >>>>>>>>> semantic versioning discussion, I think the intent of this was to >>>>>>>>> so >>>>>>>>> if there are broken tests in 0.4-SNAPSHOT of a module which are >>>>>>>>> fixed >>>>>>>>> by pulling in 0.4-SNAPSHOT of its dependency then its dependency >>>>>>>>> should be updated. >>>>>>>> >>>>>>>> No, this is not about semantic versioning (yet). >>>>>>>> >>>>>>>> This is about the following: Consider bundle X depends on the API >>>>>>>> org.apache.aries.y.api of bundle Y. Now some implementation of this >>>>>>>> API >>>>>>>> in package org.apache.aries.y.impl of bundle Y has a bug which must >>>>>>>> be >>>>>>>> fixed. In this case the dependency of bundle X on Y should not be >>>>>>>> changed. >>>>>>>> >>>>>>>> Regards >>>>>>>> Felix >>>>>>>> >>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> Felix >>>>>>>>>> >>>>>>>>>>> This will lead us towards being able to release by module but it >>>>>>>>>>> implies >>>>>>>>>>> a change in development practice. I will make the pom changes >>>>>>>>>>> locally >>>>>>>>>>> and test them but I'd like to check that release-by-module is >>>>>>>>>>> still >>>>>>>>>>> the >>>>>>>>>>> goal and that you all think this is a reasonable way to be able >>>>>>>>>>> to >>>>>>>>>>> achieve it. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Zoė >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> Cheers, >>>> Guillaume Nodet >>>> ------------------------ >>>> Blog: http://gnodet.blogspot.com/ >>>> ------------------------ >>>> Open Source SOA >>>> http://fusesource.com >>>> >> >> > >
