[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [wtp-dev] Branching Strategy plus other topics, especially JUnit tests
|
Konstantin,
Let's make an official branching policy.
We've been too loose in the past and it was confusing.
Lawrence mentioned the one official
branching requirement, that 1.5 maintenance would be in a branch called
R1_5_maintenance (I think he
left off the 'R' though :)
This is done for all the map files (releng
project)
And ... each component branches only
if/when they need to (otherwise continue 2.0 development in HEAD).
And, I'd prefer that the final versions
that are in the 1.5 release to have a tag (not branch) of
R1_5
as this makes some cvs operations easier
(like comparing many projects at one).
I'm not sure if this will be easy for
you to do if you start 2.0 early .. and deliberatley start a
special 1.5 only branch ... but suspect
there is a way. (but, if possible, I'd skip that its bound to
be confusing 4 months from now, since
1.5.1 should branch from 1.5, etc.
You an always start your own special
KostaBranch to keep work in (and even build, etc)
if you are just talking about some short
period of extra time.
Speaking of which ... thanks for letting
us know you might have some extra time to help with some
1.5 tasks ... I'm sure if anyone can
think of anything, they'll let you know.
Me first. How about some more JUnit
coverage in those that do not have any coverage? See
http://download.eclipse.org/webtools/downloads/drops/S-1.5RC3-200605182217/apiresults/full_test_coverage/api-tc-summary.html
Seems an easy task to add tests just
to make sure plugins are present and the bundle can be started.
(And, I just happen to know that the
RDB team would appreciate some help with some of the basic getting started
test plugins :)
Or, perhaps a performance benchmark
to see how many other plugins are activated when one plugin is purposely
activated?
Or .. perhaps some full Callisto performance
or UI testing? With everything installed?
Or .. if you're really "hooked"
on only working on only facets .. looks like there is not 100% coverage
there yet?
Maybe you could be the first to reach
100%? And test to make sure Jeffrey's tool is working right? :)
As a reminder to us all ... I think
the PMC would be very open to approving "bugs" that just added
JUnit "coverage tests" .. these are not the API JUnit tests we've
focused on in the past ...
but Jeffrey has started using TPTP to
measure the test coverage of our implementation ... another important indicator
of project health and platform readiness.
So .. lot's to do!
Thanks
"Konstantin Komissarchik"
<kosta@xxxxxxx>
Sent by: wtp-dev-bounces@xxxxxxxxxxx
06/06/2006 01:11 PM
|
Please respond to
"General discussion of project-wide or architectural issues."
<wtp-dev@xxxxxxxxxxx> |
|
|
To
| "General discussion of project-wide
or architectural issues." <wtp-dev@xxxxxxxxxxx>
|
|
cc
|
|
|
Subject
| [wtp-dev] Branching Strategy |
|
Does WTP have an official branching strategy?
Does it matter if all plugins branch in the same way as long as the right
versions end up in the map files? I’d like to start working right now
on 1.5.1 and 2.0 tasks, but I do not want to hold the changes local until
1.5 ships. I am thinking about using the following branch plan for the
faceted project framework plugins. Note that that 1.5 version of the facet
plugins would ship from a branch under this plan.
2.0 (main)
(now) ---------------------------------------------------|
(2.0 ships)
|
|
1.5
|----------|
(1.5 ships)
|
| 1.5.1
|---------------------| (1.5.1 ships)
On a related note, has a criteria been defined
for the 1.5.1 release? What type of changes will be admitted? Will there
be an approval process?
- Konstantin
_______________________________________________________________________
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries
and affiliated
entities, that may be confidential, proprietary, copyrighted
and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev
