[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[wtp-pmc] Re: Moving faceted project framework codebase
|
Sorry for coming late to this. I'm only just lifting myself out of the
Helios release frenzy...
You've only implied a graduation in this note. When do you intend to
graduate?
What roadblocks do you believe will be removed by moving the existing
code base into fproj? Honestly, it seems to me that the maintenance
burden will be the same. In fact, I'd think it'd be more. Right now, you
have the benefit of there being multiple committers in the current home.
Just some thoughts.
Wayne
Esteemed members of WTP PMC,
I would like to join one of the upcoming PMC calls to discuss moving
the existing faceted project framework code base from WTP Common to
the Faceted Project Framework (fproj) project under Technology. The
fproj project already contains the v-next code line for the framework.
I originally thought that it would make sense to leave the existing
code line in WTP while v-next is being developed, but experience over
the past year has shown this structure to be less than optimal. It is
more difficult than necessary to propagate changes from the
maintenance line to v-next, the community is fragmented between two
projects (forums and mailing lists) and governance issues can present
a challenge.
In terms of logistics, I’d like to propose the following:
1. Wait until Helios is complete.
2. Do a move review.
3. Ask EMO to copy relevant plugins and features from WTP CVS location
to the new project. This will preserve all the history.
4. Start producing builds from this code line. Same plugin id’s,
feature id’s, package names, etc. will be used as in WTP.
5. WTP build is altered to consume these binaries instead of building
from local source.
6. Ask EMO to delete the moved plugins and features from WTP CVS
repository.
The result will be a 1.x code line for maintenance and backwards
compatibility work sitting alongside 2.x (v-next) code line. WTP would
consume 1.x builds for foreseeable future. When version 2.0 is ready,
the next 1.x release will be a backwards compatibility shim that will
let existing code written against 1.x releases work with 2.0
framework. Tentative release schedule is as follows:
1.4.1 – aligned with Helios SR1 dates
1.4.x – other service releases as necessary
2.0/1.5 – part of Summer 2011 release
Thanks,
- Konstantin
--
Wayne Beaton, The Eclipse Foundation
http://www.eclipse.org
