Hi Giovanni, Thanks for your thoughts on this. I've commented inline.
On 29 November 2012 16:54, Giovanni Júnior <[email protected]> wrote: > > 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. > > Yes, that is a good point. That said, I suspect that for many would-be users, their entry point will be to use a quickstart archetype. Assuming that each of the editions provides such an archetype, then the drive-by user won't necessarily be bothered if the versions of those match or not. If later on a user wants to pull in modules from different editions, then we can help out on the mailing list. > 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). > > Indeed, I wouldn't expect us to provide every single combination. > 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. > > I can see the sense in that.... and in practice, I think this is what is likely to happen. My expectation is that wicket/restful/JDO will be released regularly. If and when the other "editions" want to push out a release, I'm likely to make sure that the wicket/restful/JDO is also fit-to-go and can be included. That edition would therefore be a de-facto base. One thing that we could do though (and Rob Matthews and I have discussed this several times over the years) is to spawn off some separate git repos, one per main module. So, the core would advance 0.3.0, 0.4.0, 0.5.0 and the owner of each module could either choose to release that module or not, as their time/inclination allows. That is, probably, the correct thing to do. It's what projects such as Maven and Hadoop do. > 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. > > If you look at the website now you'll see that on the documentation page [1] I am now indicating the current release status. The instructions for replacing are (now) actually pretty easy enough: it's a matter of commenting in the appropriate line in isis.properties, along with providing a supplemental configuration file for the module in question (eg persistor_datanucleus.properties for the JDO/DataNucleus objectstore). > P. S.: Considering that Isis is becoming a top-level project, Has become :-) > 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. > Ah yes. We should. Patches always welcome. Cheers Dan [1] http://isis.apache.org/documentation.html > 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 > > > > > > > > > >
