Front page | perl.perl5.porters |
Postings from October 2009
2009/10/14 demerphq <demerphq@gmail.com>: > $ for c in $(git log --pretty="format:%H" v5.11.0..HEAD); do git > describe $c; done > v5.11.0-22-gb268001 > v5.11.0-21-gad69478 > v5.11.0-20-g19a1ea5 > v5.11.0-19-gf864084 > v5.11.0-18-g3d80bce > v5.11.0-17-g28e464f > v5.11.0-16-gec81ed5 > v5.11.0-15-g1154543 > v5.11.0-14-g577f3cc > v5.11.0-13-g6eeabd2 > v5.11.0-12-gb9fb583 > v5.11.0-11-g95aef5c > v5.11.0-10-g9a7a324 > v5.11.0-9-ge74a3e7 > v5.11.0-8-g8e08567 > v5.11.0-7-gf4a6a71 > v5.11.0-6-gd0a59c9 > v5.11.0-5-g2a61b33 > v5.11.0-4-g9eea45e > v5.11.0-3-g6f6ac1d > v5.11.0-2-g085fe5e > v5.11.0-1-g9911515 > > > You think those are in any way ambiguous? Not ambiguous, but useless. They don't tell me in which branch they are. >>> Let us draw a little picture. Starting from 5.12.0 : >> >> * <- tag v5.12.0 >> | >> |----------------------------------\ >> | | >> | * a doc fix commit, >> |---\ | HEAD of branch "feature/docfixes" >> | | | >> | | | >> * bump version to 5.12.1. | >> | | | >> *<-----------[merge]---------------| >> | | | >> * HEAD of branch "maint-5.12" | >> | | >> | | >> * bump version to 5.13.0 | >> | | >> *<--------[merge]--------------/ >> | >> * HEAD of branch "blead" >> >> So we have, on our 3 branches : >> >> where: perl version -v long version output -V >> feature/docfixes 5.12.0 5.12.0 (5.12.0-1-gdcfedcfe) >> blead 5.13.0 5.13.0 (5.12.0-3-gdeadbeef) >> maint-5.12 5.12.1 5.12.1 (5.12.0-3-gbeefdead) >> >> That way, once again, we know everywhere what perl version we're using. > > I dont see what relevence what you wrote here has to the question of > when to "bump" the version. Bumping the version as a way to mark which branch we're in. I see that Nicholas suggested to use -f pod/perl5XYZdelta.pod as a marker, which would work too. Maybe it's a bit awkward to derive $] from that, though; but that eliminates redundancy. > It seems to me, unless im missing something this is true of both proposals. > >> The "5.12.0-3" output would not be sufficient to distinguish clearly >> between blead, maint and feature/*, because the current version of perl >> is not something git knows anything about. Or should know anything >> about. > > I dont get you at all. the v5.11.0-3-g6f6ac1d tells you all you need to know. > > Its 3 commits away from 5.11.0, and its sha1 is 6f6ac1d. But not the branch name ! That's why I took 5.12.0 (not 5.11.0) as an example; because a commit tagged v5.12.0 would be included both in blead and in maint-5.12. (among other branches) But, git-describe would return v5.12.0-N-gHHHHHH for commits in every branch, before a new tag is created. The point is that for any number N, I can have multiple commits for which git-describe returns v5.12.0-N-<some SHA1>, and the SHA1 is not human readable. I can't promptly use it to triage smoke emails, for example (unless I have a git-aware procmailrc. Which I don't) > >> And that way we can keep having browseable and indexable smoke reports. >> Having all branches reporting themselves as 5.12.0 would be a mess. > > At some point the 5.12.0 and 5.13.0 branches diverge, i guess at that > point you tag it 5.13.0, and then you dont have this problem. Until > they diverge and all the commits are shared, i dont see the problem. > Its the same code. Why should it be smoked twice? Those branches would differ as soon as the version is bumped, or a new perldelta created. One of those at least would happen very soon after release.Thread Previous | Thread Next