| RE: [wtp-pmc] Moving faceted project framework codebase |
|
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 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 |