[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [imp-dev] Re: FYI: IMP SVN repository has been reorganized to "standard" structure
|
Why not tag all features with every release, even though some have not changed? It costs nothing, takes no significant space in the repo, and you don't have
to update the version numbers of the features you don't release again. That way a release tag always represents a full "bill of materials".
On the other hand, the releng tools might have a feature that allows one to check out a full release including all compatible features starting from a top feature.
I prefer the low-tech solution however.
Cheers,
Jurgen
On Mon, Aug 31, 2009 at 5:35 PM, Robert M. Fuhrer
<rfuhrer@xxxxxxxxxxxxxx> wrote:
The reason for keeping features at a higher level than releases is that we don't necessarily release new versions of every feature at each release (at least not theoretically). Nominally, features can be released independently, and each feature identifies through its depdendency metadata the versions of other features with which it's compatible.
Oh, and yes, it's true that we happen to have released every feature in most of the recent releases, but that's partly b/c the releng tools have been broken for a while (since we moved to SVN), and without them, it's a pain to determine which features have actually changed since the previous release.
On Aug 30, 2009, at 1:26 PM, Jurgen Vinju wrote:
Hi,
I'd swap release and feature, such that one can check out an entire set of features that are guaranteed to work together in one go.
After all, that's what the tags are for.
Cheers,
Jurgen
On Sun, Aug 30, 2009 at 12:10 AM, Robert M. Fuhrer
<rfuhrer@xxxxxxxxxxxxxx> wrote:
Ah, good. I was particularly concerned that your critical eye might find fault. :-( / :-)
To be a little more concrete about the release tagging scheme, I'm thinking of the following:
svnroot/technology/org.eclipse.imp
tags
feature1
release1
plugin1
plugin2
...
feature2
release1
plugin1
plugin2
...
release2
plugin1
plugin2
...
...
Sound good?
If people agree, this will be the structure the releng tools will construct (once I get them working again).
On Aug 27, 2009, at 8:57 AM, Jurgen Vinju wrote:
I've used the new situation. No problems detected.
The suggestion to use the feature versions is good, and to copy everything that goes into the feature with it.
Cheers!
Jurgen
On Thu, Aug 27, 2009 at 2:07 AM, Robert M. Fuhrer
<rfuhrer@xxxxxxxxxxxxxx> wrote:
Hi Folks,
While warming up for the next release, I finally got around to reorganizing the IMP SVN repository. The new organization should make the most common case (checking out HEAD of a set of projects on the trunk) much simpler, and aligns the repository with the conventional structure used by other projects.
I believe you should be able to continue to use your existing workspaces, but it might be sensible to start fresh to avoid confusion.
So, instead of:
svnroot/technology/org.eclipse.imp
plugin1
branches
tags
trunk
plugin2
branches
tags
trunk
...
the repository now looks like this:
svnroot/technology/org.eclipse.imp
branches
branch1 - most of these were IMP-wide branches (e.g. "Eclipse-3_2")
plugin1
plugin2
...
branch2
plugin1
plugin2
...
...
tags
OLD
plugin1
tag1 - these were all per-plugin release tags (e.g. "release-0.1.1")
tag2
plugin2
tag1
tag2
...
trunk
plugin1 - all of these are now adjacent (yay!)
plugin2
...
N.B.: The organization of the "tags" folder above reflects the fact that the all of the existing tags were per-plugin, rather than per-feature or IMP-wide. In other words, it didn't make sense to group the 0.1.1's (for instance) together by putting the 0.1.1 at the top level of the "tags" folder.
We now need to decide how to tag the projects on new releases.
I'm leaning toward tagging all of a feature's plugin projects with the feature's version number.
Comments?
_______________________________________________
imp-dev mailing list
imp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/imp-dev