To put it differently, there's no single IMP version #, but there are version #'s for the various IMP features. So I don't know how I would organize the tags if the feature folder isn't topmost (under "tags", that is).
On Aug 31, 2009, at 1:24 PM, Jurgen Vinju wrote: 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
_______________________________________________ imp-dev mailing list imp-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/imp-dev
|