I would prefer to follow Rob's suggestion. Most of the times the example may need certain version of framework to work. Also the tagging and branching will be easier.
- Henry On Sat, Jun 25, 2011 at 10:31 AM, Dan Haywood <[email protected]> wrote: > OK, well, if the preference is to make larger-scale changes, then I think > there are two main options. > > Either (as Rob suggests): > > trunk/ > framework/ > examples/ > domain-libs/ > tags/ > framework/ > examples/ > domain-libs/ > branches/ > framework/ > examples/ > domain-libs/ > > or: > > framework/ > trunk/ > tags/ > branches/ > examples/ > trunk/ > tags/ > branches/ > domain-libs/ > trunk/ > tags/ > branches/ > > > For myself I marginally prefer the latter, because I see the framework, the > examples and the domain-libs as being separately release-able; and in > general any set of modules that might have its own release lifecycle ought > to have its own trunk/tags/branches pair. > > Does anyone else have any opinions on this? Mentors... what do other Apache > projects that you contribute to do? > > Thanks > Dan > > > On 25/06/2011 10:46, Robert Matthews wrote: >> >> Dan >> >> While it would easiest to keep trunk where is all the code is actually >> related, so tagging and branching would be all over the place. I would >> prefer a structure more like:- >> >> trunk/ >> framework/ >> pom.xml >> core/... >> ... >> examples/ >> ... [A] >> domain-libs/ >> ... [B] >> tags/ >> whole project tag >> ... >> framework/ >> framework tag >> ... >> examples/ >> example tag >> ... >> domain-libs/ >> domain libs tag >> ... >> branches/ >> whole project branch >> ... >> framework/ >> framework branch >> ... >> examples/ >> example branch >> ... >> domain-libs/ >> domain libs branch >> ... >> >> Regards >> Rob >> >> >> On 25/06/11 08:40, Dan Haywood wrote: >>> >>> Hi all, >>> As you probably saw, the vote for 0.1.2-RC4-incubating didn't get >>> through, the main reason that some people voted on one version of >>> source-release (the one I manually uploaded from my target directory to my >>> home address), and others voted on the one that mvn automatically uploaded >>> to the staging repo. That fact invalidates the vote. I'll update the >>> release process in the contributors guide so that in future we only call a >>> vote on the one uploaded to the staging repo (which for various boring >>> reasons would also seem to be better, ie have less/no spurious artifacts in >>> it). >>> >>> Anyway... since we need to go round the loop yet again, it seems that I >>> may as well address some minor issues that - while not showstoppers - could >>> be tidied up. >>> >>> One of these is arranging things so that the examples and domain-libs >>> modules, which are not part of the main modules, don't get zipped up into >>> the source release. To address this, I think it means we need to move them >>> out of trunk. >>> >>> What I propose is to go from: >>> >>> trunk/ >>> pom.xml >>> core/... >>> ... >>> examples/... [A] >>> domain-libs/... [B] >>> tags/ >>> branches/ >>> >>> to: >>> >>> trunk/ >>> pom.xml >>> core/... >>> ... >>> tags/ >>> branches/ >>> examples/trunk/ >>> ... [A] >>> domain-libs/trunk/ >>> ... [B] >>> >>> >>> I realize this isn't quite symmetrical, but I think I'd like to have >>> "trunk" where it is (ie >>> https://svn.apache.org/repos/asf/incubator/isis/trunk rather than >>> https://svn.apache.org/repos/asf/incubator/isis/framework/trunk or some >>> such). >>> >>> If anyone has any objections, let me know. I'll not do anything for the >>> next 72 hours or so, to give everyone chance to read this and respond (ie 72 >>> hour lazy consensus). >>> >>> Thanks >>> Dan >>> >> >
