[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [wtp-pmc] Moving faceted project framework codebase
|
For completeness, my recommendation was that Konstantin work to build a
mature Faceted Project Framework project with a diverse community of
adopters and committers. And that at some point in the future (i.e.
after the new framework has graduated and proven that it can stand on
its own) he should work with the WTP project to integrate the new
framework in favour of the old.
Wayne
Konstantin Komissarchik wrote:
Members of WTP PMC,
After consulting with Wayne and after due consideration, I have
decided to fork Faceted Project Framework 1.x code line into the new
project under Technology, where it will evolve together with the 2.0
codeline as a backwards compatibility shim.
Since it’s a fork rather than a move, WTP PMC approval is not
required. The forked codebase (the future shim) will retain the
existing package names, bundle ids and feature ids. The versions will
track what WTP releases and be set appropriately higher.
I will continue to fix bugs in WTP version of the codebase. I will
also test the shim in the context of WTP scenarios, but of course the
level of testing that the shim will receive will be far lower as the
bulk of WTP developers and community testers will be testing with WTP
version of the code. At some point in the future, the new project will
exist incubation, 2.0 framework and shim will be ready, and other
projects will adopt this technology (via the 2.0 api). I hope you can
see where I am going with this... An EPP or an adopter’s custom
package where WTP is running against a different version of facets
than what it was tested with.
I do not make this decision happily. I think this option is far worse
for WTP than the move would have been, but this seems to be the only
viable way forward. I disagree completely with the rationale presented
by WTP PMC in denying the move request and I not wish to see the
technology that I have worked on for so many years stagnate. While
this framework does satisfy current WTP requirements, this technology
is far from fulfilling its true potential and it cannot do that while
it is tied to WTP.
Thanks,
- Konstantin
*From:* wtp-pmc-bounces@xxxxxxxxxxx
[mailto:wtp-pmc-bounces@xxxxxxxxxxx] *On Behalf Of *Konstantin
Komissarchik
*Sent:* Wednesday, May 26, 2010 1:43 PM
*To:* wtp-pmc@xxxxxxxxxxx
*Subject:* [wtp-pmc] Moving faceted project framework codebase
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
