Hi
I think it's worth taking a user perspective on these version numbers.
Eclipse has one major version number; 3.5 for Galileo. It is a pain
remembering that the
corresponding version of e.g EMF is 2.5. It is more convenient to refer
to the 3.5 version of EMF.
IMP is not important enough to have more than one version number. IMP
users will take all
or nothing. I don't think IMP is used in embedded scenarios where code
bloat is a big issue.
Regards
Ed Willink
Robert M. Fuhrer wrote:
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
_______________________________________________
imp-dev mailing list
imp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/imp-dev
|
