isis-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Haywood <...@haywood-associates.co.uk>
Subject Re: [DISCUSSION] Release process - fine tuning
Date Tue, 11 Dec 2012 23:36:13 GMT
On 11 December 2012 23:26, Robert Matthews <rmatthews@nakedobjects.org>wrote:

> Dan
>
> 1. A quick look at Eclipse and I'm struggling to see any seemingly random
> placing. All my components are together and so on. What I do have though is
> very long names as the group ids are also showing. This is set up in the
> Eclipse plug-in settings. That said I'd rather have shorter project names,
> and after making the change to shorter name everything is all over the
> place.  I'm happy with the proposed naming convention as I prefer the
> benefit of the ordering. That said, the core modules will still appear
> randomly.
>

Yeah, if you import with the advanced > template of [groupId]:[artifactId],
then everything is indeed ordered logically.

However, when Jeroen and I tried this on Monday, we decided not to use this
template, and just went with the default template, which is just the
artifactId.

Try it... you'll see it's quite a mess.

I was just playing around with Idea 12, and (I think) it also does the
equivalent, of naming its projects based on the artifact.




>
> 2 & 3. My previous expectations were that the core would be released at a
> particular point and the components would then be released independently to
> work against the core, and would probably be re-released again against the
> same core as they get improved. So the components would evolve more quickly
> than the core and the core would be improved in the background. (Although
> isolated fixes to the core would be made without causing the components any
> concern.)
>
> Yes, no change... that's my expectation as well.



> WRT the parenting, are we expecting the core modules to stay in step - all
> released each time - or will specific modules be release as they needed?


All the core modules would be released together, yes.



> An alternative strategy to the two options you suggested would be for the
> parent pom to be released as part of the core, that way it would always be
> ready for the components. Generally, though, I'm still trying to get my
> head around how this could/would/should work.  Maybe a skype call, were
> share our thoughts, might be worth while at this stage.
>

I think this is basically the same as having everything parented by core's
pom.  Indeed, the more I think about it, the more I am happy to go this
way.  I'm trying it out in a branch locally to see how it flies (ie testing
to see if I release core and then if I can release one of the components).




>
> 3. Such numbering makes a lot of sense. And as you say a large number is
> just a large number.
>

Ok, that's three of us in agreement.  It might be worthwhile doing a formal
vote on this one; perhaps in a day or two.



>
> Regards
>
> Rob
>
>
>
>
>
> On 12/10/12 20:17, Dan Haywood wrote:
>
>> 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.
>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message