+1 This would make releasing so much easier. But it could also be interpreted it as a guilt- free pass to break other editions in order to release your own. And what does the master branch represent in this scenario?
Cheers, Jeroen On Thu, Nov 29, 2012 at 4:39 PM, Dan Haywood <[email protected]>wrote: > Hi Matthew, > > That's a good insight/metaphor. Agreed. > > Your mail prompted me to look a little deeper into how the Apache release > process in the master POM [1] creates the src.zip (actually, I note it's > called source-release.zip). And, as you hinted at, it is created by the > maven-assembly-plugin, during the release:perform stage. And in fact the > name of the artifact is already parameterized as the > ${sourceReleaseAssemblyDescriptor} parameter. > > So, picking up on your idea, I think we could have profiles that: > (a) list a set of <modules>, and (b) override this parameter. > > To do a release would consist of: > > release:prepare - tags and edits the poms > release:perform -P xxx - builds the source zip for the "edition" and > deploys this zip and the binary artifacts to be voted on. > > That seems better to me. It would mean that a retrospective release of > other editions from the same tag would require a separate run of > release:perform and their own vote, but that's probably for the best. > > Thanks! > > Dan > > > On 29 November 2012 15:09, Matthew Adams <[email protected]> wrote: > > > Wouldn't these certified objectstore/viewer combos be called "assemblies" > > (maven), "distributions" or "distros" (geeks & me) or "editions" > > (marketeze), then? Like, "Isis: JDO/Wicket Edition" and "Isis: > > NoSQL/Scimpi Edition", etc. > > > > Maven profiles could be used along with maven-assembly-plugin to produce > > the editions, and there would be a one-to-one relationship between Maven > > profile and edition. > > > > -matthew > > > > > > On Thu, Nov 29, 2012 at 8:36 AM, Dan Haywood > > <[email protected]>wrote: > > > > > This discussion post is mostly to the contributors, but cc:ing to user > > list > > > for opinions also... > > > > > > ~~~ > > > > > > At the moment it's a daunting task to fully verify all the components > of > > > the framework are working correctly prior to pushing out a release. I > > > suppose that wouldn't be so much of a concern if we had better > automated > > > tests, but, hey, that's how things are. > > > > > > Moreover, frankly, some of the modules are best considered spikes and > > > probably don't constitute something that we would consider > > > production-ready. Or, at least, they haven't been used in a real-world > > > context, so it's not possible to say whether they are really > > > fit-for-purpose. I include here quite a lot of the stuff that I have > > worked > > > on over the last few years, eg the wrapper-progmodel, the groovy > > progmodel, > > > probably also the JUnit viewer and BDD viewer. Now that we are a > > top-level > > > project, I'd like it that the code we put out is thought of as > production > > > ready. > > > > > > In order to make the framework easier to release, I propose that we use > > > Maven profiles to be able to release subsets of modules, that a given > > > contributor can stand behind and say: "yes, those modules are working > and > > > are fit for general consumption". Each release would consist of the > > certain > > > core modules, along with selected additional viewers and object stores. > > > > > > For example, over time we might end up releasing: > > > > > > * v0.3.1 core + objectstore-jdo + viewer-wicket + viewer-restfulobjects > > > // a "wicket/jdo release" - eg tested and released by Dan > > > > > > * v0.4.0 core + objectstore-nosql + viewer-scimpi // a > "scimpi/nosql > > > release" - eg tested and released by Rob > > > > > > * v0.5.0 core + objectstore-dflt + objectstore-xml + viewer-dnd // > a > > > "dev env release" - eg tested and released by Rob > > > > > > * v0.6.0 core + objectstore-jdo + viewer-wicket + viewer-restfulobjects > > > // another "wicket/jdo release" > > > > > > * v0.7.0 core + objectstore-sql + viewer-html // a "html/sql > > release" - > > > eg tested and released by Kevin > > > > > > * v0.8.0 core + objectstore-jdo + viewer-wicket + viewer-restfulobjects > > > // another "wicket/jdo release" > > > > > > Whenever a release goes out, we would update our website to indicate > the > > > most recent version of the components. > > > > > > Now, when I say "release", what I actually mean here is the deployment > of > > > binary artifacts up to the Maven central repo. This, after all, is what > > > most users/would-be users in the community would use and consider a > > > release. However, Apache's own formal definition of "release" is > actually > > > the source code release ... this is what the [VOTE] mechanism is for. I > > > don't see this changing... the vote basically says that the software > > > complies with all the legal license stuff etc. The whole codebase is > > tagged > > > with that release number, and the generated src.zip is a zip of this > > > release. > > > > > > One benefit of this is that it allows the deployment of other modules > to > > be > > > performed "after the fact". For example, suppose that I (Dan) puts out > > the > > > v0.3.1 release as above, and then Rob later on tests the scimpi viewer > in > > > that tag and finds it works well. He can (I think) push the release of > > the > > > scimpi viewer up to Maven central repo. > > > > > > As I see things there are several benefits to this scheme: > > > > > > a) (as already noted) the user community will only see binary releases > > that > > > are known to be of production ready. This should mitigate the "is it > safe > > > to use this component" worry > > > b) (as hinted at) it should be possible for individual contributors to > > put > > > out releases of their modules more rapidly > > > c) we get visibility of which modules aren't being released; for > example, > > > we might say that if a module hasn't been released by anyone for 18 or > 24 > > > months, say, then it's probably time to remove it from the codebase. > > > > > > ~~~ > > > > > > In order to support the above scheme, I propose that we rearrange some > of > > > the modules so that they can be more easily included within Maven > > > modules. I've > > > created a page on our wiki [1] which shows my proposed rearrangement. > It > > > also repeats the above discussion text by way of context. > > > > > > > > > Opinions welcome! > > > > > > Thx > > > > > > Dan > > > > > > > > > [1] > > > > > > > > > https://cwiki.apache.org/confluence/display/ISIS/Make+releases+easier+and+more+frequent > > > > > > > > > > > -- > > mailto:[email protected] <[email protected]> > > skype:matthewadams12 > > googletalk:[email protected] > > http://matthewadams.me > > http://www.linkedin.com/in/matthewadams > > >
