You are viewing a plain text version of this content. The canonical link for it is here.

Posted to users@isis.apache.org by Dan Haywood <da...@haywood-associates.co.uk> on 2012/12/10 21:17:19 UTC

[DISCUSSION] Release process - fine tuning

All,

Following on from the previous discussion thread relating to renaming of
artifacts etc, I've been doing some further work on the release process, up
to and including have now pushed our isis-core up to the Nexus staging
repo.  Won't be calling a vote, just wanted to see if it all worked using
git (which it does, after a few modifications).

Anyway, we have a few alternatives in some of the detail; if you have an
opinion on any of this, please respond...


1. artifactId names: eg isis-jdo-objectstore vs isis-objectstore-jdo

This point came up in the previous thread, and at the time I was ambivalent
as to which way we went on it.  Now, though, I think we should use the
"reverse polish notation", ie "isis-objectstore-jdo".

The reason is mostly this: if a developer imports the entire project from
the root aggregator pom (oai:isis-all) into Eclipse, then the project name
will (by default at least) be based on the artifactId.  This means that
artifacts appear pretty randomly in the Eclipse workspace.

Of course, the same argument applies if listing a directory, eg ls
WEB-INF/lib.

Opinions?


2. Should our releasable modules (core and each of the 20-ish components)
have a separate org.apache.isis:isis-parent as their parent (which defines
the maven-release-plugin configuration etc), or should they all use
org.apache.isis.core:isis as their parent.

The benefit of the former (and the code is mostly organized this way) is
that, well, it seems to follow what many other maven projects do.  But the
downside is that we would need to release this isis-parent artifact first,
and we might tend to forget about it and not update it.

The benefit of the latter is we will always re-release it whenever there is
a new release of core, and - as a bonus - all the child modules will
inherit version definitions by way of <dependencyManagement>.

Put another way: do we think that the lifecycle of our release process
itself  be decoupled from the lifecycle of releases of Isis core?  If yes,
we should have a separate org.apache.isis:isis-parent.  If no, we should
just use org.apache.isis.core:isis as the parent of all releasable modules.

Opinions?


3. What should our version numbers be?

This is quite a big one, possibly worth its own thread, but I was wondering
if we should adopt semantic versioning [1].  Thus, this first release will
be v1.0.0 of the core; any bug fixes would be 1.0.1, 1.0.2, any backwardly
compatible enhancements (to the APIs) would be 1.1.0, 1.2.0, any breaking
changes to the APIs would be 2.0.0, 3.0.0, etc.

There's an argument that things aren't quite stable enough in core to do
this; the counter argument is that they are just numbers; if we end up with
isis-core v 12.0.0 in two years time because of a succession of breaking
API changes, so what?

Opinions?


Thanks
Dan

PS: fyi, I'm hoping to be in a position to put a release out of isis core
for voting by the end of this week or beginning of next, latest.


[1] http://semver.org.

Re: [DISCUSSION] Release process - fine tuning

Posted by Kevin Meyer - KMZ <ke...@kmz.co.za>.

Just so long as you are happy that no-one will think that the
 
>      isis-inmemory-objectstore -> isis-core-objectstore

is the core object store.. or somehow core to all objectstores.

Otherwise, go with the previous suggestion:

>>  isis-inmemory-objectstore   ->  isis-core-objectstore-inmemory  


But, I suppose that with a suitable description in the class comment, it 
should be easy to make it clear that "isis-core-objectstore" is a simple 
implementation and must be replaced in a production environment, 
then that name is fine.

Kevin