FYI Jeremy and I had a chat on IRC and here is the outcome, which Jeremy is going to act on while I get some sleep
spec/sdo stays where it is samples/sdo gets moved to sdo/samples ditto distribution/sdo the sdo source distribution is split into a spec archive and an implementastion archive (impl, tools, plugins,samples, ..) we tag by copying sdo similarly spec/sdo we create a release policy that says that when a tag is taken the tagger copies the up to date project STATUS document into the tagged hierarchy the parent pom and the buildtools also need to be tagged I'll capture this stuff on the wiki nad plan to sanitize it into a release policy Jeremy pointed out http://incubator.apache.org/guides/proposal.html as a good style for such a doc, as having a good balance of what, why and how. I think that's a fair summary of the chat, thanks Jeremy. On 01/10/06, kelvin goodson <[EMAIL PROTECTED]> wrote:
Jeremy, yes EMF 2.2.1 is available, and I was looking to sort that on Friday afternoon when I realised I had missed the samples from the distribution. This again reflects the fact that our sub project organisation is a bit awkward, However, I do recall a fairly extended mail exchange about how the samples should be organised, and we resolved -- samples/sdo, samples/sca etc., so that would have to change. I think perhaps the fact that we have decided to be able to release separately is sufficient reason to override the earlier decision. As to cutting a release, Can we describe/decide how this will work please? My understanding from the IRC chat last week was that we would only want to ask for a vote on one releasable entity. So my assumption is that that would be a bundle of the releasable artefacts from the 3 subprojects. If so, then I think I am in a holding pattern here for SDO, and all I can do is cut and post another release candidate with the non-snapshot EMF dependency. Is that correct? Regards, Kelvin. On 30/09/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote: > > If we are going to start releasing these separately (or really just > being prepared to) then I think this would be worth doing. It's a > fairly simple change to do even now so should we do this for this > release? > > Speaking of which, it looks like EMF 2.2.1 is available from their > maven repo. AIUI that was the last thing that was needed before > cutting a release - should we start that process? > -- > Jeremy > > On Sep 26, 2006, at 4:09 AM, kelvin goodson wrote: > > > I have made a branch for SDO at > > http://svn.apache.org/repos/asf/incubator/tuscany/branches/sdo-java- > > M2/which > > I thought it might be worth drawing your attention to, since it might > > be helpful that we had a common approach across the projects. I > > think we > > are going to want separate branches per project, as we will be > > ready to > > branch at different times. > > > > I had to assemble my branch with a couple of svn mkdirs and three > > svn copy > > commands, which feels a little awkward. It begs the question of > > whether, > > post M2, we should consider having all the sub-project stuff under > > one svn > > folder, e.g. java/sdo/spec, java/sdo/distribution, java/sdo/impl -- > > rather > > than the current java/distribution/sdo, java/spec/sdo and java/ > > sdo. I think > > this would be much cleaner, and easier to cut source distributions > > too. We > > could then have java/sdo/branches. This is in line with best > > practice as > > given by the svn free book http://svnbook.red-bean.com/en/1.1/ > > ch04s07.html. > > What do you think? > > > > Regards, Kelvin. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
