Hi everyone, Please excuse my Google Translate english...
I don't know much about the development and packaging process of Isis yet, and I agree with any improvements that streamline it, but I want to make a comment, hoping I haven't read the above too fast. Assuming that the numbers v0.3.1, v0.4.0 etc correspond to sequential releases, users normally expect their content to be similar. Therefore the "distributions" approach suggested by Mathew, also used by Eclipse. But in the case of Isis, I fear that this approach wouldn't work well, since there are several interchangeable modules that would cause an explosion of distributions (Cartesian product or almost that). In my view, a better approach is to have only a "basic" distribution, containing just the modules that an ordinary user would most likely use (eg sql objectstore + wicket viewer + restful). The team should commit to maintain those modules stable in all releases. Besides that, the website and the documentation would show the status of each of the other modules in each release, along with instructions on how to use them to replace the basic distribution modules. P. S.: Considering that Isis is becoming a top-level project, as outlined above, I think we should plan an effort to gradually pay the technical debt that seems to exist in the automated testing area of the project. Regards, Giovanni 2012/11/29 Jeroen van der Wal <[email protected]> > +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 > > > > > >
