| Summary: | Switch maintenance builds to auto-tagging | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Dani Megert <daniel_megert> |
| Component: | Releng | Assignee: | Platform-Releng-Inbox <platform-releng-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | curtis.windatt.public, david_williams, dj.houghton, jarthana, john.arthorne, markus.kell.r, Michael_Rennie, pwebster, satyam.kandula, srikanth_sankaran, tjwatson |
| Version: | 3.6.2 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Dani Megert
Kim, can you set this up for R3_6_maintenance R3_7_maintenance R4_1_maintenance and inform the committers on platform-releng-dev once this is live? Thanks a lot! I can add the repositories.txt in all those streams. I have added the repositories.txt for: R3_6_maintenance R3_7_maintenance The R4_1_maintenance build is currently using the "short build" that we are aiming to replace. Paul, I suggest either you switch this build to auto-tagging, or we wait until it switches over to the full builder. (In reply to comment #3) > The R4_1_maintenance build is currently using the "short build" that we are > aiming to replace. Paul, I suggest either you switch this build to > auto-tagging, or we wait until it switches over to the full builder. OK, I've switched the short build to the auto-tagging fix. PW I was running test build today for the R3_7_maintenance branch changes and it seems that the jdt.core.binaries and rt.equinox.incubation don't have R3_7_maintenance branches. I'm sure the issue is that nothing has changed since the release, but I'll ask the teams to create them. Tom, please create a R3_7_maintenance branch for rt.equinox.incubation repo Srikanth, please create a R3_7_maintenance branch for the eclipse.jdt.core.binaries repo Done for equinox.incubator http://git.eclipse.org/c/equinox/rt.equinox.incubator.git/log/?h=R3_7_maintenance (In reply to comment #5) > I was running test build today for the R3_7_maintenance branch changes and it > seems that the jdt.core.binaries and rt.equinox.incubation don't have > R3_7_maintenance branches. I'm sure the issue is that nothing has changed > since the release, but I'll ask the teams to create them. Satyam, please (a) create the branch and (b) also see if our bundle version needs to be bumped up to work with the new auto-tagging based version strings, TIA. Please add a note here when you are done. Created the R3_7_maintenance branch for jdt.core.binaries. Also updated the bundle versions to support new auto-tagging based version strings. Should have mentioned this yesterday but the autotagging for the 3.7.x builds is now working. Kim, it looks like this is in place for 3.7.x now. How about 3.6.x? One thing I noticed is that it uses the same tag pattern as in the I-builds (e.g. v20111129-2053). Before (CVS land) we added an additional pre- or post-fix to denote the maintenance branch, e.g. v20111130_r372 or r372_v20111117. Could we add this back? Most likely we'd choose a post-fix, given that we now already started to use v*. (In reply to comment #11) > One thing I noticed is that it uses the same tag pattern as in the I-builds > (e.g. v20111129-2053). Before (CVS land) we added an additional pre- or > post-fix to denote the maintenance branch, e.g. v20111130_r372 or > r372_v20111117. Could we add this back? Most likely we'd choose a post-fix, > given that we now already started to use v*. We didn't use this in platform ui, as the bundle version in the maintenance stream was enough to prevent qualifier clashing. While I personally don't like it in the qualifier, I'm fine with it as a postfix if that's what the other teams would like. But: I'd like to see this optioned in the master script if included ... I know in e4.releng trying to keep the same script mostly in sync in 3 streams was horrible, and I finally chose to make the master script work for all branches that need to be built. PW +1 for revealing the stream in the tag (e.g. as postfix v20111130_r372). While this is not absolutely necessary in the bundle qualifier, it still helps for spotting versioning problems. Furthermore, it makes it possible to detect the stream from the tag name, which is very important if you have to check something in the repository. Currently, the tags are just an unstructured list, and it's a pain if you e.g. have to find the previous tag from a given one. (In reply to comment #13) > +1 for revealing the stream in the tag (e.g. as postfix v20111130_r372). > +1 also, I know this has been helpful in the past in easily detecting that a particular bundle has any fixes in an SR. > Kim, it looks like this is in place for 3.7.x now. How about 3.6.x?
Ping! Also for 'R3_6_maintenance_Java7', please ;-)
What's the state here?
Can anybody confirm or correct this list and then close the bug?
build input (all map files in Git): | source from:
auto-tagged | needs manual tagging | Git | CVS
R3_x_maintenance for x<6: - x ? ?
R3_6_maintenance: - x x -
R3_6_maintenance_Java7: - x x -
R3_7_maintenance: x - x -
R3_8_maintenance: x - x -
R4_2_maintenance: x - x -
I'm coming to this conversation late ... and am sure there are things I don't understand ... but can confirm we have auto-tagging for R3_8_maintenance: R4_2_maintenance: But, given that we do not even have any public builds of R3_x_maintenance for x<6: R3_6_maintenance: R3_6_maintenance_Java7: R3_7_maintenance: then I think it is up to each adopter to work out their own internal build approaches for those. Ideally they should have their own internal forks of maps, builders, etc., and build however they would like. So ... I suggest we take any further discussion offline and work with Steve to figure out what's needed (for those asking :). (I think if auto-tagging is not already working for those older builds, its best to stick with old tag and update map files approach since presumably would not be worth investing in build changes for what is likely to be just a few patches?). If I've misunderstood, and there is some "public" / community aspect of this I'm not aware of, just let me know. (In reply to comment #16) > What's the state here? > > Can anybody confirm or correct this list and then close the bug? > > build input (all map files in Git): | source from: > auto-tagged | needs manual tagging | Git | CVS > R3_x_maintenance for x<6: - x ? ? > R3_6_maintenance: - x x - > R3_6_maintenance_Java7: - x x - > R3_7_maintenance: x - x - > R3_8_maintenance: x - x - > R4_2_maintenance: x - x - I agree that this bug can be closed and things should be left as is. Just for the records: R3_x_maintenance for x<6: all (incl. map files) is in CVS. Releng Tool is used to do the build input (i.e. *no* manual tagging). |