-
15. Re: Requirements - Top level build - versioning
Ok. The LATEST notion is still too vauge. It is currently restricted due to the fact that there is a banch that tends to limit when new binaries are added. When opened up to a full repository with arbitrary versions, LATEST does not make sense to me.
A qualified notion of latest in a given series would make more sense. In terms of identifying such a version, it seems that there is a need for a top level respository descriptor which expresses the compatibility info. -
16. Re: Requirements - Top level build - versioning
By top-level I meant the top of a given component version, not across all components in the repository:
repository.jboss.com/ hibernate/ version-info.xml 3.0.5/ component-info.xml lib ...
-
17. Re: Requirements - Top level build - versioning
We were talking in the past about having different notions of LATEST
e.g.
LATEST-BLEEDING-EDGE: The head from cvs (source checkout only)
LATEST-COMPILED (cruisecontrol was able to compile it)
LATEST-TESTED (all unit tests pass)
LATEST-INTEGRATED (unit tests and integration tests pass)
I even suggested that the compiled/tested be moving tags within CVS.
Currently with CVS we only have the bleeding edge. :-)
I think most developers would prefer to work at LATEST-INTEGRATED
on projects they are not currently developing. -
18. Re: Requirements - Top level build - versioning
You would of course only be able to do check-ins if you have the
LATEST-BLEEDING-EDGE -
19. Re: Requirements - Top level build - versioning
So would the version-info.xml record the "LATEST" notion?
And also recorded the "tested with" notion? -
20. Re: Requirements - Top level build - versioning
Doesn't the notion of LATEST vary by project and by branch? IE, just because jboss-portal upgrades to log4j 10.2 doesn't mean that every other component or project in the universe is ready to.
We should combine the materialize and pegging features.
Pegging the versions in the toplevel build reproduces the current behavior/expectations of storing libraries in CVS.
Using the materialize target to generate/validate the pegged versions improves communication around versioning issues without creating total confusion as to which version of a component is being used in a developer's build. -
21. Re: Requirements - Top level build - versioning
"ryan.campbell@jboss.com" wrote:
Doesn't the notion of LATEST vary by project and by branch? IE, just because jboss-portal upgrades to log4j 10.2 doesn't mean that every other component or project in the universe is ready to.
I would say the opposite, but it depends what you mean by LATEST.
If Bela is going to release a new jgroups, Bill a new aop, etc.
we would want to test this before release for integration issues, then use
it once tested. "LATEST-INTEGERATED"
But we don't want to be doing this while Bela/Bill are developing with changes
that might break their head "LATEST-BLEEDING-EDGE", otherwise
nobody will be able to get any work done :-).
Anyway, I think you are correct that we need to stay with something close
to what we know and introduce changes in incremental steps. Otherwise when
it breaks, we won't know which change in the process is the problem. :-) -
22. Re: Requirements - Top level build - versioning
So would the version-info.xml record the "LATEST" notion?
And also recorded the "tested with" notion?
Yes, that is what I am thinking.
The latest notion is not a function of project or branch. A given project wants to qualify the meaning of latest such as latest in the log4j 1.2.? series. Top level builds do not combine, so there can be no conflict in which latest is in effect.
There can be a conflict if portal switches its latest view, and also becomes incompatible with previous versions of log4j. -
23. Re: Requirements - Top level build - versioning
We were talking in the past about having different notions of LATEST
e.g.
LATEST-BLEEDING-EDGE: The head from cvs (source checkout only)
LATEST-COMPILED (cruisecontrol was able to compile it)
LATEST-TESTED (all unit tests pass)
LATEST-INTEGRATED (unit tests and integration tests pass)
So the term latest is quite ambiguous, and from this perspective at least LATEST-INTEGRATED is project specific. The others are useful snapshots of a given project cvs tree.
If LATEST-INTEGRATED were a measure of compatibility with a reference project such as jbossas I suppose it has some value for other projects that need to integrate in jbossas. Otherwise, I don't know what it means. -
24. Re: Requirements - Top level build - versioning
"scott.stark@jboss.org" wrote:
So the term latest is quite ambiguous, and from this perspective at least LATEST-INTEGRATED is project specific. The others are useful snapshots of a given project cvs tree.
Yes obviously, you would need this per top level build that integrates the project
and per branch of that top level build.
If LATEST-INTEGRATED were a measure of compatibility with a reference project such as jbossas I suppose it has some value for other projects that need to integrate in jbossas. Otherwise, I don't know what it means.
Wouldn't this be LATEST-INTEGRATED-JEMS?
i.e. this is the "lowest common denominator" version that works with everything. -
25. Re: Requirements - Top level build - versioning
Anyway, the need for "LATEST" which was to reproduce the "bleeding edge" cvs
notion for binary checkouts, isn't as strong now that cvs is no longer a bottleneck.
I still think it is a useful notion to track projects through the integration process.
But this is something for the future.