Kelvin summarized the chat nicely but I'd like to add a little
background.
Cutting the branch for SDO was a little fiddly and if we're going to
do this on a regular basis then the process should be simpler. We can
script it, but scripting something that's fairly fragile is not going
to be reliable.
As an open source project, it's important for us to be able to easily
cut a source distribution that represents the state of the project at
some point in time so that people can build their own version. The
approach we are taking for this release is to cut a source
distribution (represented by tag in SVN and a archive of that tag)
and then build binaries from it. This allows us to verify that the
build actually works from that distro, and means that users can trust
that the binary we are distributing matches the source.
We're separating distribution of the spec and of our implementation
of it. The expectation is that the spec source/binary will change
independently of our implementation. This is even more true for SCA
where the spec group at the moment is not producing its own
distribution of the APIs. Our implementation will reference a binary
version of the spec APIs - the source distro will compile against the
spec jar, the binary distro will include the spec jar. Users will be
able to use the spec on its own (with any implementation), or if they
use our implementation will automatically get the spec jars as part
of it.
The SDO samples are moving under the java/sdo root to allow them to
be tagged with the rest of the implementation. This will keep the
layout of the source distribution the same as the development tree so
that we don't need to change any of the build. The same will happen
with the distribution sub-project so that users of the source distro
can build the binary distro the same way we do.
One problem we have is with the STATUS file that lives in the root of
the tuscany project tree and records the state of the whole project
rather than any of the technical subprojects. We need to include it
in the source distro (and the tag that represents it). The easiest
solution we have so far is to add a manual step to the tag-making
process where the tagger copies the file into the tag tree.
We also have an issue with the samples and how to include them in the
binary distribution. Kelvin is going to look at that tomorrow.
--
Jeremy
On Oct 1, 2006, at 2:09 PM, kelvin goodson wrote:
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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
