On 11 December 2012 23:26, Robert Matthews <rmatth...@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. >> >> >
