Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [wtp-dev] Proposal to move to "3.2 Style Builds" using ".qualifier"even for 1.0.1

+1.

 


From: wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx] On Behalf Of David M Williams
Sent: Tuesday, January 24, 2006 5:07 AM
To: wtp-dev@xxxxxxxxxxx
Subject: [wtp-dev] Proposal to move to "3.2 Style Builds" using ".qualifier"even for 1.0.1

 


I'd like to propose we move the same style of builds we are currently
doing for WTP 1.5, even in for our WTP 1.0..1 builds.

The motivation for this is this would allow us to start using the same ".qualifier" form of plugins now,
in WTP 1.0.1, and make for easier transition in a). our code streams, b). our experience with it,
and c.) future updates to 1.0.x, and 1.5. In short, its easier to have set of naming rules, than two.

The only reason this is a "proposal" instead of me just doing it, is that there's a tiny side effect,
that does have some tiny risk.
The compiler we use to produce the byte codes of our builds is the JDT compiler, and technically
speaking, there is a difference between the version of the compiler in
the "3.1 style" builds vs. the "3.2 style" builds. I have gotten  word from the JDT team that the
byte codes produced should be "as good or better" in the 3.2 pre-release version, but ...
But, it does technically mean "a bigger change" than I'd normally recommend in a point release,
so wanted to float this as a proposal, and see if anyone knows of reasons not to do this.

In this case, I think the tiny risk is worth the improvement in versioning number rules, especially
since our 1.0.1 version and our M5 versions will be fairly close together in time.

So, if there are objections (or, if you'd just like more time to consider), let me know. Otherwise,
I'd propose we do this as soon as this week's M-build is declared. To do in steps, after weekly M-build
declared, we'll first do a build with the 3.2 style build-tools, then I'll give the word that
the .qualifier can be added to both streams. Then, if there are some weird unanticipated problems
we would have time to 'back out' or otherwise react by next week's M-build.

Thanks,

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

The following are some misc. tidbits that are related, for those interested in the nitty gritty.

1. All this is gated on us using the "basebuilder tool" from the platform team.
I have tried (and tried and tried) taking just the new "PDE" part of the build (for the new .qualifier behavior)
and using the "old" 3.1 compiler, but it didn't work and I don't think it could easily.

2. Just FYI, using .qualifier in he old "3.1 style" builds actually works! but, produces qualifiers
with just the timestamp of each build, not the version ID in the map file. This is not only
not helpful for updates, it will later be confusing when we start to use "cvs tags" as the .qualifier.

3. We can not easily "update"  from 1.0 to 1.0.1 anyway so no great harm in updating
all the plugins. (other than the size, but the 30 megs or so are not all that prohibitive).

4. I have, btw, tried this on a local build, and saw no obvious problems.

5. There is no effect on downstream components, as they would typically merely
"require" 1.0 versions, and they would continue to do that.

6. Just to be explicit, this does not effect or change us pre-reqing Eclipse 3.1.x as our base for
WTP 1.0.1 ... that part is all the same, and is independent of the basebuilder tool that is
used to actually create the packaged bytecodes.


Back to the top