[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipselink-dev] Incubation component minutes
|
I am not misunderstanding you, I am advocating branching of the
incubation projects along with Eclipselink. For users looking for an
Incubation project they would know compatibility by the stream the
project was found in. Aligning branches is intuitive and would be
expected by SVN users. After doing a little more research it seems that
individual projects could include their own branches if needed. I would
be happy with that approach switching work involved in removing projects
from branches with precise naming and parallel branching. It resolves a
lot of the issues I was anticipating with no branching of the incubation
projects. The directory structure would be as follows:
\incubation
\project1
\trunk
\branches
\project2
\trunk
\branches
\SupportForEclipseLink1.0 (or another appropriate name)
--Gordon
Eric Gwin wrote:
Gordon,
I think you are misunderstanding me. I am not talking wholly about
development decisions, but also about the repercussions due to the
constraints of the tools. Subversion WILL branch everything under
trunk when trunk branches. Therefore
trunk
\--incubation
\--- proj1
\---proj2
will result in branched incubation projects. Thus forcing a
maintenance of two streams (unless one is abandoned - Which forces
deletions, or clutter).
However, subversion also allows mixed checkout, so where incubation
resides in the repository makes no difference to where it is checked
out in a view (nor should it effect checkout in an IDE environment).
For instance, a project that wants to maintain close dev ties to
trunk, could reside in an incubation project outside of trunk:
\-- trunk
\- incubation
\--- myproj
but still be developed side-by-side in a view like:
trunk
\---foundation
\-- myproj
\-- ...
You are correct that we would need to think about branching strategies
for incubation.. perhaps duplicating the project at branch-time would
work.
trunk trunk
\--incubation -------> \--incubation
\--- myproj
\---myproj1.1
\---myproj2.0
-Eric
Gordon Yorke wrote:
Branching incubation projects with the EclipseLink streams will in no
way force these projects to maintain multiple streams. It will be
the choice of the individual projects if they want to maintain
compatibility with a previous EclipseLink stream. Eliminating the
branching does however produce barriers to the incubation projects
that may wish to have multiple streams or those that may wish to
develop within a particular stream. If an incompatibility is
introduced in the trunk projects with branches will also have the
option of returning to a previous stream while continuing to develop
new functionality in the trunk. It should be expected that many of
these incubation projects will have lifecycles that include multiple
main stream branches.
--Gordon
Eric Gwin wrote:
I think that having it under trunk is a bad idea - it simply adds
more maintenance headaches and clutters the tree.
I'm assuming that the incubation project(s) will be worked on by a
few key committers as time permits. This means that getting the
project "EclipseLink ready" could take a while, and resources will
be limited.
Do we really want to force maintenance on multiple branches, or
leave abandoned copies out there?
Not to mention that conceptually everything under trunk is part of
our "current" development release, just like everything under
branches/1.0 is everything for our 1.0.x release stream. The whole
intent of the "incubation" project is that it isn't part of a release.
I still think it is easier and makes more sense to store it above
the trunk (actually the same level as the trunk) and maintain a
document that says.. This incubation component is being developed to
run using "x.x.x" of EclipseLink
(among other things like what it is supposed to do, how to use it,
dependencies it needs, etc.)
Then once it reaches production quality it is folded into
EclipseLink and the incubation project is removed. and it branches
along with everything else.
-Eric
Peter Krogh wrote:
I wasn't clear in my first email. We all agreed that we should
create the componant. The discussion point was around whether the
directory should be in trunk or parrallel. Doug has proposed
trunk. Any objections? I know that there were a couple of
concerns brought up durring the meeting about what that means to
branching.
-----Original Message-----
From: Douglas Clarke Sent: Thursday, December 04, 2008 9:56 AM
To: Dev mailing list for Eclipse Persistence Services
Subject: RE: [eclipselink-dev] Incubation component minutes
I believe Tom's topics listed below should be clearly addressed in
the Wiki page each incubation project/component maintains.
I also believe that these should incubate within trunk. It will be
up to each owner to manage the state of the incubation effort when
we branch. In general I would see these as remaining in trunk until
they mature into the main code line.
Doug
-----Original Message-----
From: Tom Ware Sent: Wednesday, December 03, 2008 4:16 PM
To: Dev mailing list for Eclipse Persistence Services
Subject: Re: [eclipselink-dev] Incubation componant minutes
We also need to identify what information should be provided for
each incubation component. (perhaps in a readme)
- What version does it work with
- Any build instructions
- Any usage documentations
- Other things?
Peter Krogh wrote:
During todays call we discusses the incubation idea, proposed by
Doug, at length.
Some discussion points arose.
Incubation Componant
Should the incubation directory be under trunk or parrallel to
trunk?
How to handle 3rd party dependancies?
I assume that a consumer of the incubation code would need
to download the dependancy themselves, as opposed to opening CQs.
Any others?
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
