Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Luna RC4 staging repo is complete

The reason we don't do that is because that would be the same as "releasing it" ... that, and the URL ..../release/luna is "built in" to all prior Luna milestones and candidates, so people with "auto update" set would all start hitting '' the moment it was there, before there was opportunity to mirror.

I think it's very common for many projects (such as Tycho) to be available in a "staging" location for a period, before officially moving to the "released" location.

Perhaps this FAQ would help?

Thanks for suggesting ways to improve the process, though.

From:        Igor Fedorenko <igor@xxxxxxxxxxxxxx>
To:        cross-project-issues-dev@xxxxxxxxxxx,
Date:        06/19/2014 07:55 AM
Subject:        Re: [cross-project-issues-dev] Luna RC4 staging repo is complete
Sent by:        cross-project-issues-dev-bounces@xxxxxxxxxxx

Little late to the party, but I'd like to suggest adding RC4 to Luna
composite and making this part of symrel process going forward. By
"hiding" RC4 under obscure URL we artificially limit amount of testing
it gets and make it harder for downstream projects validate their code
will still work yearly release comes live next week.


On 2014-06-11, 23:52, David M Williams wrote:
> As I am sure you all know, this is our final aggregation build for Luna,
> unless a blocking issue is found.
> I always like to emphasize, that, at this point, a "blocking issue" that
> would lead to a re-spin has to be more than a typical "bad problem" for
> a one project ... but more along the lines of something that "destroys
> all data in a project or workspace" or "prevents installs or updates of
> other projects from occurring" or that sort of thing. If you do find a
> bad bug that effects just  your project's function, I encourage you to
> a) look for and document "work arounds" and/or b) prepare a "project
> level patch"  that you could make available by the time we release, so
> users can take advantage of it immediately after they install the
> release. This is purely for stability reasons ... that is, it is often
> better to "ship" with a known bad bug, than to risk fixing one bug and
> exposing something even worse (which would be hard to find in time,
> since by then little time left for testing). And just so I don't seem
> negative ALL the time ... if you sincerely believe you found a bug that
> really would be bad for the reputation of Eclipse as a whole, or
> something, discuss with your project and PMC and other Eclipse leaders
> and if they all believe it worth mentioning here on cross-project list,
> then please do. Even if the answer is "no, no re-build", it doesn't hurt
> to keep everyone informed.
> Also important for you to know, this "staging" repo is NOT moved to
> .../releases/luna on Friday, like we normally do, since that is Friday
> the 13th [JUST KIDDING!]. The real reason it just stays on staging is
> that would essentially be "pre-releasing" the whole train. Instead we
> always have a "quiet week" for final preparations, final adopter testing
> and builds, etc., and then formally release it (make visible) on the
> long scheduled date of Wednesday, June 25th.
> I will be sending out a "what to do during quiet week" note in the next
> day or two (some version of "Kepler Final Daze
> <>" document, updated for Luna).
> Let us know if questions or issues, by posting here to this
> cross-project list.
> And my personal thanks for those final pushes for improvements in "repo
> reports <>" -- no
> missing "about" files, good improvements in unsigned bundles, and some
> improvement in making feature licenses (SUA's) current. We'll continue
> to work towards perfection for SR1 and Mars!
> Much thanks to you all,
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
cross-project-issues-dev mailing list

Back to the top