I'm not quite sure what the R gives you over the I :) In the end you still have to remember a name that is not obvious like 3.6.0 or Helios-SR0In the platform we preferred going with a funny name rather than rebuilding / massaging. This way, we are actually sure that what we are shipping is indeed what we tested. Long ago we use to do some version bashing where all versions were in sync etc, however this did not really play well with updating (actually one of the reason why we could not update since everything always had the same version) and left a strange after taste since you were never really sure that the operation had proceeded as expected. The other thing with the bashing is now what if you discover a problem after you renamed to R, you have to re-build and you will end up producing another R build which in the end will pollute your R space.
On 2010-06-11, at 9:15 AM, Kenn Hussey wrote: If the platform is OK with having a build identifier like "I20100603-1500" in their release (rather than something like "R20100617-1500"), then I guess we should be too. In that case, there's no need for us to rebuild after all - we'll just copy our (current) repository over and rename our (current) ZIPs like other projects do. Sorry for all the fuss.
Thanks,
Kenn On Thu, Jun 10, 2010 at 5:54 PM, Kim Moir <Kim_Moir@xxxxxxxxxx> wrote:
We just copy our final build repository
to our release repository. We also have scripts that rename
all the zips to the release name. So no repacking, or re-signing
for us :-)
Kim
06/10/2010 03:46 PM
|
To
| |
cc
|
|
Subject
| Re: [cross-project-issues-dev] Final
Release Build |
|
David,
I guess the complication stems from our initial misunderstanding
of "final build" in the Helios release schedule; we expected
to be able to run and contribute our "release" build next week
(even if it were based on the same CVS timestamp). I believe others had
similar (or perhaps even greater) expectations, so we're not alone there.
We've already identified the need for a "rename"
operation (or something similar) for Buckminster builds, but I'm not sure
if there is a bug for it yet; if there isn't, I'll create one and add you
to the CC list.
What do other projects do? Does "renaming" for
other projects involve unpacking zips/JARs, updating identifiers and/or
paths, and then repacking/resigning them? Or do folks simply republish
their existing bits as new repositories and ZIP archives? I would think
the former, unless, for example, folks expect something like "I20100603-1500"
to be the build identifier of the official release....
Kenn
On Thu, Jun 10, 2010 at 3:09 PM, David M Williams <david_williams@xxxxxxxxxx>
wrote:
> the feature numbers change with each build because
the build identifiers change
Interesting. Complicated. I know there are plenty of issues of when to
call a build "different".
Thanks for letting us know what to expect:
to see changes in build files and that your final build will change qualifiers
of features and branding bundles,
in order to be named correctly. If anything substantial changes I'm sure
you'll let us know.
But sounds like you will _require_ a rebuild/spin/push of all of Helios's
1,000,000,000 bytes to accommodate your build system and make sure
everything matches. (did I do that math right? 1 to 2 Gigabytes, depending
on how you count).
Is there a bug/feature request for handling renames with Buckminster based
builds? Sounds important (that is, it would be best to produce
final bits/versions early and then later decide those were indeed the bits
to release, without having to rebuild). I'd like to follow that discussion.
[And, honestly, sounds like you could have planned better ... how do you
know your "final rebuild to change the name and URLs" is really
the right one to release? that nothing broke?]
We are here to help! :)
Well, in the case of the EMF, XSD, and Ecore Tools builds, the feature
numbers change with each build because the build identifiers, which are
stored in the about.mappings files of the branding bundles, change. But
the other (i.e., source code) bits would remain the same. Is this acceptable?
Kenn
On Thu, Jun 10, 2010 at 12:53 PM, David M Williams <david_williams@xxxxxxxxxx>
wrote:
Well ... let's see ... does it set office furniture on fire? :) Just kidding.
Yes, if just the URL of the final repo changes, and all feature/bundle
versions stay the same, I won't complain.
If some version number change (even if in qualifier only) I'd appreciate
understanding why that was ... since that implies different bits.
Thanks,
I think what Ed means is that some projects need to respin their builds
(against the same bits) using a different build type (e.g., "R"
instead of "I") and those builds need to be published to a different
repository location (release repo instead of milestones repo) before the
final release. I assume such projects should be considered exceptions so
that they are picked up by a final "on demand" aggregation?
Kenn
On Thu, Jun 10, 2010 at 11:06 AM, David M Williams <david_williams@xxxxxxxxxx>
wrote:
Not sure. And, not sure I know what you mean. Normally when I hear "rename"
it just involve zip files and directory names. Do you mean the directory
part of the URL in the .build file? In the past, people have just corrected
those to final location (after the release, normally) and does not require
a respin. This is not ideal, obviously, since we are not literally building
from the final URL, but, honestly, we always have the risk that the contents
of a URL changes and breaks the build, or makes it non-reproducible.
If I've not answered what you need to know, please ask again.
Thanks,
David,
Given that we don't have rename support for our Buckminster builds, how
will be spin and contribute our final release build?
Regards,
Ed
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
|