| Summary: | [releng] Rename download zips to include stream? | ||
|---|---|---|---|
| Product: | [Eclipse Project] e4 | Reporter: | DJ Houghton <dj.houghton> |
| Component: | UI | Assignee: | Project Inbox <e4.ui-inbox> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | aniefer, daniel_megert, john.arthorne, kim.moir, pwebster, remy.suen, thatnitind |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
DJ Houghton
Hi Andrew What do you think? It might be easier to rename the 4.x stream builds instead of 3.7 because this effects a lot of downstream teams right now (fetching base to compile against etc). Maybe something like eclipse4-sdk... is clear enough. I wouldn't want to put specific version numbers like 4.0, 4.1, etc. Yes, I agree that this is better done on the 4.x side. I had noticed this myself and was considering changing it but never got around to it. John, since milestone and final release builds get renamed to include their specific versions (eclipse-SDK-3.7M5-win32.zip vs eclipse-SDK-4.1M5-win32.zip) I don't really see the problem with just using eclipse-SDK-4.1-* (In reply to comment #3) > John, since milestone and final release builds get renamed to include their > specific versions (eclipse-SDK-3.7M5-win32.zip vs eclipse-SDK-4.1M5-win32.zip) > I don't really see the problem with just using eclipse-SDK-4.1-* I was worried that someone might interpret that filename as being *the* 4.1 release. It is not the 4.1 release - it is an integration build working towards the 4.1 release. Maybe it's not a big deal. I realize now that the problem goes beyond the file name. Nothing on our I-build download pages indicates what stream it belongs to. For example how would a user know what stream this build belongs to: http://download.eclipse.org/eclipse/downloads/drops/I20110222-0800/index.php Maybe that's fine too - anyone consuming our I-builds should know the difference I suppose. It gets confusing to those of us checking the compatibility layer, though, once we have I-builds from both branches on disk. Removing outdated target milestone. We no longer build multiple streams so this is no longer a problem. |