Reto Gmür schreef op 8-8-2014 13:01: > On Thu, Aug 7, 2014 at 3:05 PM, Minto van der Sluis <[email protected]> wrote: > >> In my daily work I prefer Continous Delivery. >> >> For this I configured my build server to no longer build snapshots. Only >> developers do build snapshots locally. So everything the build server >> builds is ready to be released. For this I use sort of semantic >> versioning with an additional (sequential) buildnumber. The buildnumber >> is to ensure every build gets a unique version number. >> > Interesting approach. So every build would be a release candidate and one > would just have to call for a vote. Changing the dependency version in all > dependent project would be a huge task (for the cumbersome versions plugin) > - of course, not if everything has the same version number. > >> This actually improved our workprocess. Since we never have to do a >> rebuild just to do a release. Actually having a special release build >> (snapshot --> release) creates new artifacts. Since there are new >> artifacts full regression testing should be applied. So just when you >> think your done testing, you create a release and have to start testing >> again. In our case this last step vanished since the build server >> already created something which is ready to be released in the first place. >> >> This actually makes it easy to release early and often. The artifact for >> a release are already there only wrapping things up and broadcasting the >> release needs to be done. >> >> BTW. Downside is that our maven repository grows quite fast. >> > If after every commit we would push a full release... > > So far we have 2058 commits in git, if each of them creates 200MB of > artifact in the maven repo it would be around 400GB now (for comparison, > maven central had 286GB in 2011).
Only after a release vote has passed it is necessary to deploy the artifacts to central. > > Cheers, > Reto > >> Regards, >> >> Minto >> >> Minto van der Sluis schreef op 7-8-2014 14:45: >>> Hi, >>> >>> >>>> Independently of this question I think we should re-discus the release >>>> process. I consider the release process as it is now as problematic >>> for the >>>> following reasons: >>>> 1. When releasing a module we can either release all dependent >> modules >>>> as well or move the dependencies back to the last released version. With >>>> the first approach we end up releasing modules that did not change, with >>>> the latter we have to make sure that there was indeed no relevant >>> change in >>>> the module or in any other module reached via this dependency. >>>> 2. When releasing multiple modules, those modules that are not part >> of >>>> the release have to be removed from reactor and deleted in the release >>>> branch, otherwise they will be part of the source-zip. As after the >>> release >>>> we want to merge back the changes to the version number to master, we >> have >>>> to do a complicated selective merge as we don’t want to merge back the >>>> removal of modules nor the downgrading of dependencies. >>>> >>> Looking from a user perspective (as using clerezza components). I'd >>> rather like all components to have the same version number. Like this I >>> don't have to think about which component versions work together. I >>> expect all component with the same version to work together well. In my >>> opinion this is option 1. >>> >>> I don't mind about unchanged components being rebuild with a newer >>> version. Actually I prefer it like this since it gives me confidence for >>> the reason I gave before (everything with the same version works well >>> together). >>> >>> To me its one of the first decisions we have to make. >>> [a] Release the whole with a single version number >>> [b] Release individual component with their own version number. >>> >>> I favour option [a]. Also option [a] makes using the maven versions >>> plugin a lot easier. >>> >>> Who else? >>> >>> Regards, >>> >>> Minto >>> >>> >> >> -- >> ir. ing. Minto van der Sluis >> Software innovator / renovator >> Xup BV >> >> Mobiel: +31 (0) 626 014541 >> >> -- ir. ing. Minto van der Sluis Software innovator / renovator Xup BV Mobiel: +31 (0) 626 014541
