[cross-project-issues-dev] Changes coming soon to Orbit download pages a

[David M Williams <david_williams@xxxxxxxxxx>]

None of these changes should break or negatively
effect anyone ... but, they are large enough they deserve some explicit
mention here on cross-project list, just in case. 

If it does effect anyone ... let us
know over in Orbit ... open a bug, or comment on one of the existing ones
mentioned below. 

1) (small) change to retention
policy for active builds: We will
still keep everything forever that was ever "released", as before,
but we are going to be a bit more aggressive in removing _old_ versions
from active builds for the next release. For example, instead of continuing
to build 7 versions of ICU ... we might just build the most recent two
or three versions ... everyone should be on the most recent version anyway
(in most cases), and if you need a older one, it will still be there in
the archives. And no removals after M6. Just open a bug if you need something
'active' that we removed. [Initial, low hanging fruit made repo 25% smaller
(200 M to 150 M) so it will be worth some streamlining!]. 

2) massive "installable" zip
replaced by massive zip of p2 repository. It should be of more general
use. The old one was made for the old "install by unzipping into eclipse"
model, which has not even worked anyway for Orbit bundles, for a very long
time. Now you can actually have a local copy of the whole zipped repo,
and use it in your target runtime. (bug
274837).

3) URL for http access repo documented
on each download-build page. (All experienced release engineers knew where
it was ... but no one else).   (bug
274837). Again, should be able
to use it in your runtime targets. 

The above items can be "seen"
in the latest
I-build, the rest will be implemented
soon. 

4). The get-http style of map file has
been marked as "deprecated", and we encourage release engineers
to use the p2 style in their builds. It should be very easy to migrate
to consume p2 style. Do let us
know if not. The get-http style will not be going away anytime soon ...
but, we are going to make some "internal" changes to its exact
data so a) always a tiny risk of it not working as before (a very tiny
risk in this case) and b) if anyone has any custom programs which do some
custom parsing of these map files you might want to check if you've hard
coded any assumptions on URL paths or unzipping bundles that are supposed
to be unzipped. (See bug 334488).


5). Ok, I lied ... this item might effect
some developer's routine workflow ...  if you are old fashioned and
work like me. :) Until now, the link to individual bundles on download
pages have been pointing to either jars or zip files, the zip extension
was a small hack to make the files "self documenting" -- they
should be unzipped if zip extension, or, leave as jars, if a jar extension.
To avoid redundant processing and storage we'd like to just point to the
jars in the repository so the "documentation" of whether or not
to unzip will be on the download page itself, and you'll have to check
if a jar should be unzipped in your install. This does not effect anything
if you use map files in your builds. This does not effect anything if you
use p2 to install bundles or add a runtime target. This might effect you
only if you construct your own custom development environment and individually
download and "install" a bundle into 'dropins' folder (or similar),
which should be unzipped (like ant, or soap) so an alternative to reading
download page information is to use p2 and/or take advantage of using runtime
targets. But do please comment in bug 334487
if you think this change is negative
and we'll reconsider. (I am probably the only person left who does it the
old fashioned way :) 

Thanks,