Hi Vincent & Neto,
Sorry I didn't respond sooner, but I've been distracted by work. Besides, build/release management is one of my least favorite aspects of s/w engineering because I'm no good at it (or maybe it's the other way around ;-)
I talked with our JBoss Tools release mgmt engineer about this (you may know him, Mickael Istria) and he has offered to work with you to figure out what is the best way to organize the update sites for all of the target platforms.
Please keep me in the loop and let me know if I can do anything to help (for instance, updating the eclipse project website?)
Thanks!
Bob
Hi Neto,
Le 05/04/2012 11:01, Neto a écrit :
Well,
OK, but with which platform?
JBoss Tools needs a build against Helios.
Petals Studio needs a build against Indigo, but the Helios version
works on Indigo.
And the next official release is built against Juno.
Helios builds are done on every commit.
Juno builds are launched manually. These builds are packed and
signed (as defined by the Eclipse release process), which takes
longer.
Next year, there will be another platform. And this is just about
the builds.
We need one update site for the releases, and one for the snapshots.
Besides, the BPEL Designer has moved into the SOA top-level project.
So, the final update site must be under "soa" and not "technology"
anymore.
My questions were about clearing the way it should work. :)
I proposed one location per platform / build job, plus one location
for the promoted builds (under "soa"), pushed manually and for the
last platform only (Juno this year).
Previous promoted update sites should be moved to
archive.eclipse.org.
Vincent.
_______________________________________________
bpel-dev mailing list
bpel-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/bpel-dev
