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
>
