+1 For reason a) , ease new users in. Best Regards
Mike Burton (Sent from my iPhone) On 29 Nov 2012, at 14:36, 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
