[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: RES: [cross-project-issues-dev] Question about Build ID's

David,

I need to ask a question because our current setup based upon how I interpreted what I read is different than your email implies is standard. Our process:
- We (EclipseLink) create a build (stamped with date and code revision),
- if our automated tests pass clean it is a possible milestone candidate.
- when we want to release a milestone, we run further manual test suites on the
chosen milestone candidate
- if they pass and we approve the milestone we promote the build to the
milestone level (bits remain the same - status changes).


I mention this because I have setup P2 sites for our latest 'nightly' build, our latest milestone, our releases, and our eclipse contribution. At this point our latest milestone repository matches our eclipse contribution site. At release, I was simply going to promote our last milestone "RC2" to our release thereby adding 1.1.2 to our release location, but leaving the last milestone and eclipse contribution P2 sites unchanged. I don't see any need to change the eclipselink.build to reflect a new location. I may be missing some part of the larger process though. Can you clarify?

Is there some reason that the build must point to the "release" site?

-Eric


David M Williams wrote:

The last day was yesterday ... or, today, it appears from all the requests being made!


Sorry it is not clear, but the idea is ... at least my understanding ... is that your build file right now, for final build, just points to your final content, even if that content is in a "temporary" site, such as "milestones". Hence, what we create is final content, and is just stored in /staging temporarily.

So, after that, say Monday, as you "move" things to your final site, say /updates you should change your .build file to point to that final, permanent /updates directory but there would be no change in content (no change in features or feature versions), so no need to rebuild Galileo.

Let me know if I am misunderstanding, or if there are additional questions.

I'll try to improve 'final daze' document to capture some of this.



Inactive hide details for "Paula Gustavo-WGP010" ---06/18/2009 10:12:18 AM---Hi david, Just to clarify."Paula Gustavo-WGP010" ---06/18/2009 10:12:18 AM---Hi david, Just to clarify.


From: "Paula Gustavo-WGP010" <wgp010@xxxxxxxxxxxx>

To: 	
"Cross project issues" <cross-project-issues-dev@xxxxxxxxxxx>

Date: 	
06/18/2009 10:12 AM

Subject: 	
RES: [cross-project-issues-dev] Question about Build ID's

Sent by: 	
cross-project-issues-dev-bounces@xxxxxxxxxxx

------------------------------------------------------------------------



Hi david,

Just to clarify.
When is the last moment to update my .biuld contribution file. Is it
today or on Monday 22th? It is not clear to me based on the final_daze
wiki.

Currently we have everything set on mtj, but I understood that I had to
wait until Monday 22th to place my update jars on out release URL and
after that update my build contributions.

:)
gep

-----Mensagem original-----
De: cross-project-issues-dev-bounces@xxxxxxxxxxx
[mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] Em nome de David M
Williams
Enviada em: quinta-feira, 18 de junho de 2009 10:39
Para: Cross project issues
Assunto: Re: [cross-project-issues-dev] Question about Build ID's

> ... in my understanding,
> /releases/galileo and .../staging are the same at the moment,
> so what about doing a clean build of .../staging when PDT and
> Teneo are done with their things?

No. /releases/galileo won't be updated until 'final daze'.
http://wiki.eclipse.org/Galileo/Final_Daze
(not that it is all that explicit in that document, I just take every
opportunity to reference it in the hopes that increases it chances of
being read ... but I've mentioned it in other cross-project posts ...
obviously buried ... only /releases/staging has all the latest stuff).

I'm still waiting for someone to support the idea of re-spining teneo
and
pdt for their perceived "stop ship" problems.
Hmm, I notice dsdm-tm has updated their .build file too! :)






From: "Oberhuber, Martin" <Martin.Oberhuber@xxxxxxxxxxxxx> To: "Cross project issues" <cross-project-issues-dev@xxxxxxxxxxx> Date: 06/18/2009 06:32 AM Subject: [cross-project-issues-dev] Question about Build ID's Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx



Hi all,

I'm not sure how many other projects do this, but the TM project
embeds its build ID's into the feature description text shown in
the about dialog (via about.mappings).

Now it can happen that a build's contents does not change at all,
but the build ID changes; in the TM case, our 3.1 release is the
same as our RC4, but the build ID is "3.1" rather than "3.1RC4".

I'm wondering how the Galileo Builder treats this. Given that our
plugin and feature ID's have not changed, would the Galileo builder
take our "old" plugins with the "3.1RC4" build ID embedded from
some cache? For some plugins / features, the build ID might even
be MUCH older.

Or does it fetch fresh data from our update site on every run,
thus ensuring that the latest build ID, "3.1" is embedded?

The stuff on /releases/galileo which I just checked contains a
mixture of "RC3" and "RC4" build ID's. I'm wondering whether there
is a chance to rectify this... in my understanding,
/releases/galileo and .../staging are the same at the moment,
so what about doing a clean build of .../staging when PDT and
Teneo are done with their things?


Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm _______________________________________________ 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