Front page | perl.perl5.porters |
Postings from October 2009
2009/10/14 demerphq <demerphq@gmail.com>:
>> The goal is clear: perl -V should clearly indicate what version it is:
>> - is it an official release?
>> - is it a release candidate?
>
> Yes
>
>> - is it a perl build from a snapshot/commit? As in, X commits after an
>> official release
>
> I disagree with the terms. "snapshot/commit". Who cares if its built
> from a snapshot or commit?
>
> The point is what does the snapshot or commit *contain/represent*
>
> I mean, if i build Perl 5.10.0 from a snapshot downloaded from
> gitweb.cgi it should be no different from building it froma tarball
> on CPAN, or from a git clone/checkout.
>
> The problem is we want to be able to identify to the best of our ability
>
> a) changes that are not in our tree
> b) closest commit that IS in our tree to the version being discussed.
> c) whether there are uncommited changes
> d) whether there are unpushed changes (for a committer this is important)
> f) if at all possible what extra commits were included
> g) if at all possible what additional patches were included.
h) the branch. Which is pretty important, e.g. for smoke reports
> As far as im able to tell the choice is between this:
>
> perl-5.11.0-123-g12345
>
> or this:
>
> perl-5.11.1-devel-123-g12345
But those are not version numbers. We were discussing versioning --
when to bump the 3 number version 5.X.Y in the development cycle.
Don't mix that with tagging. As RFC 1925 says, "It is always possible
to aglutenate multiple separate problems into a single complex
interdependent solution. In most cases this is a bad idea."
After a .0 release there is typically more than one new version number,
that is, one per main branch, because you'll finally bump either to
5.X.1 or to 5.(X+1).0, depending on the main branch you're on. That
being said without making an assumption on the date where the bumping
occurs. (I call "main branches" the ones where a release is cut:
currently that's maint-5.10 or blead.)
But all those branches have their most recent tag as the latest released
version. So the tag is not sufficient.
More clearly : a smoke report subject
line currently looks like :
Smoke [5.11.0] v5.11.0-170-ge4d771f FAIL(Fm) linux etc...
Note that the version and the git-describe output present 5.11.0 as
redundant information. Moreover we lack the branch name, and
if the version is not bumped immediately after tagging, we
cannot even know by looking at the subject if we're smoking
maint, blead, or a feature branch.
Bumping the version in each main branch just after tagging
would allow us to have reports labelled : for maint, eg. 100 commits
after release of 5.12.0 :
Smoke [5.12.1] v5.12.0-100-gdeadbeef...
and for blead, also 100 (different) commits afterwards :
(note that the SHA1 changes)
Smoke [5.13.0] v5.12.0-100-gbeefdead...
which can quickly be visually discriminated.
A report for a feature branch with 3 commits in it (intended to be
merged in blead and eventually in maint) would be :
Smoke [5.12.0] v5.12.0-3-gfeedbaad...
indicating 5.12.0 + 3 patches
The git-describe output allows to identify the commit, but is not
sufficient, because a commit can merged be in several branches. So a
version number for perl cannot be constructed from git.
From that, I infer that setting the version of perl early will help
smoke and bug reporting.
>> Summary: the later it is changed the more likely it becomes that it will
>> block the release and the more work it creates for the pumpking.
>
> I dont agree with this assumption, and I don't think there is evidence
> to back it up.
All pumpkings who commented on that seem to disagree.
Thread Previous
|
Thread Next