Bug #47840 for TAP-Harness-JUnit: Changes file missing

Mon Jul 13 14:54:56 2009 MARKSTOS [...] cpan.org - Ticket created

Subject:

Changes file missing

Thanks for your work on this module. I may one day use it to connect my test suite with "Hudson". I'm filing a bug today because the "Changes" file is missing. This makes it difficult whether or not to update to a new release. Was there an incompatible change made? Was a new feature added? Was a bug fixed? Was a security issue patched? Without a Changes file, it is challenging to know. Thanks. Mark

Tue Jul 14 04:58:54 2009 lubo.rintel [...] gooddata.com - Correspondence added

Subject:	Re: [rt.cpan.org #47840] Changes file missing
Date:	Tue, 14 Jul 2009 10:58:31 +0200
To:	bug-TAP-Harness-JUnit [...] rt.cpan.org
From:	Lubomir Rintel <lubo.rintel [...] gooddata.com>

On Mon, 2009-07-13 at 14:54 -0400, MARKSTOS via RT wrote: Show quoted text

> I'm filing a bug today because the "Changes" file is missing. This makes > it difficult whether or not to update to a new release. Was there an > incompatible change made? Was a new feature added? Was a bug fixed? Was > a security issue patched? Without a Changes file, it is challenging to > know.

Thanks for the report. What you propose is definitely a good idea. Currently, you can inspect the list of changes by looking at the GIT repository [1]. I'll probably go with generating the Changes file from the GIT history somehow. http://repo.or.cz/w/TAP-Harness-JUnit.git -- Lubomir Rintel (Good Data)

Tue Jul 14 04:58:55 2009 The RT System itself - Status changed from 'new' to 'open'

Tue Jul 14 09:39:36 2009 mark [...] summersault.com - Correspondence added

Subject:	Re: [rt.cpan.org #47840] Changes file missing
Date:	Tue, 14 Jul 2009 09:39:18 -0400
To:	bug-TAP-Harness-JUnit [...] rt.cpan.org
From:	Mark Stosberg <mark [...] summersault.com>

Show quoted text

> > I'm filing a bug today because the "Changes" file is missing. This makes > > it difficult whether or not to update to a new release. Was there an > > incompatible change made? Was a new feature added? Was a bug fixed? Was > > a security issue patched? Without a Changes file, it is challenging to > > know.

> > Thanks for the report. What you propose is definitely a good idea. > Currently, you can inspect the list of changes by looking at the GIT > repository [1]. I'll probably go with generating the Changes file from > the GIT history somehow.

That method is still often difficult to read, which I suspect is why manually generated Changes file remain the most popular method. See the WWW::Mechanize project for a particularly user friendly format: http://cpansearch.perl.org/src/PETDANCE/WWW-Mechanize-1.58/Changes The commit messages you pointed to at 'git' make no mention of whether each change is a new feature, a bug fix, a security patch, or some internal or documentation update. Such clear labels can save users a good deal of digging to discover what they need to know to decide about whether to upgrade or not. What works for me is to create "Changes" entries as I go, as part of the actual commits. This saves the burden of evaluating all the changes at release time to see how to describe and classify them. Mark

Thu Jul 16 08:05:55 2009 lubo.rintel [...] gooddata.com - Correspondence added

Subject:	Re: [rt.cpan.org #47840] Changes file missing
Date:	Thu, 16 Jul 2009 14:05:30 +0200
To:	bug-TAP-Harness-JUnit [...] rt.cpan.org
From:	Lubomir Rintel <lubo.rintel [...] gooddata.com>

On Tue, 2009-07-14 at 09:39 -0400, mark@summersault.com via RT wrote: Show quoted text

> Queue: TAP-Harness-JUnit > Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=47840 > >

> > > I'm filing a bug today because the "Changes" file is missing. This makes > > > it difficult whether or not to update to a new release. Was there an > > > incompatible change made? Was a new feature added? Was a bug fixed? Was > > > a security issue patched? Without a Changes file, it is challenging to > > > know.

> > > > Thanks for the report. What you propose is definitely a good idea. > > Currently, you can inspect the list of changes by looking at the GIT > > repository [1]. I'll probably go with generating the Changes file from > > the GIT history somehow.

> > That method is still often difficult to read, which I suspect is why > manually generated Changes file remain the most popular method. See > the WWW::Mechanize project for a particularly user friendly format: > > http://cpansearch.perl.org/src/PETDANCE/WWW-Mechanize-1.58/Changes > > The commit messages you pointed to at 'git' make no mention of whether > each change is a new feature, a bug fix, a security patch, or some > internal or documentation update. Such clear labels can save users a > good deal of digging to discover what they need to know to decide about > whether to upgrade or not.

Well, we could probably label GIT commits with tags that would state whether the commit is an enhancement or whatever. Show quoted text

> What works for me is to create "Changes" entries as I go, as part of the > actual commits. This saves the burden of evaluating all the changes at > release time to see how to describe and classify them.

Does this look well? http://repo.or.cz/w/TAP-Harness-JUnit.git?a=blob;f=ChangeLog -- Lubomir Rintel (Good Data)

Thu Jul 16 09:33:23 2009 mark [...] summersault.com - Correspondence added

Subject:	Re: [rt.cpan.org #47840] Changes file missing
Date:	Thu, 16 Jul 2009 09:33:00 -0400
To:	bug-TAP-Harness-JUnit [...] rt.cpan.org
From:	Mark Stosberg <mark [...] summersault.com>

Show quoted text

> Well, we could probably label GIT commits with tags that would state > whether the commit is an enhancement or whatever.

That's true, but ofte a feature may made of several smaller patches, with names like "whitespace fix", "refactor to prepare for new feature, no logical changes" and then finally: "New Feature: Whizbang!" You could have a changelog parser that ignored all non "tagged" commits, but the automation would break if you missed tagging an entry. Show quoted text

> > What works for me is to create "Changes" entries as I go, as part of the > > actual commits. This saves the burden of evaluating all the changes at > > release time to see how to describe and classify them.

> > Does this look well? > > http://repo.or.cz/w/TAP-Harness-JUnit.git?a=blob;f=ChangeLog

Fantastic! Thanks. Mark

Thu Jul 16 09:40:35 2009 lubo.rintel [...] gooddata.com - Correspondence added

Subject:	Re: [rt.cpan.org #47840] Changes file missing
Date:	Thu, 16 Jul 2009 15:40:10 +0200
To:	bug-TAP-Harness-JUnit [...] rt.cpan.org
From:	Lubomir Rintel <lubo.rintel [...] gooddata.com>

On Thu, 2009-07-16 at 09:33 -0400, mark@summersault.com via RT wrote: Show quoted text

> Queue: TAP-Harness-JUnit > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=47840 > > >

> > Well, we could probably label GIT commits with tags that would state > > whether the commit is an enhancement or whatever.

> > That's true, but ofte a feature may made of several smaller patches, > with names like "whitespace fix", "refactor to prepare for new feature, > no logical changes" and then finally: "New Feature: Whizbang!"

Well, for GIT the typical workflow is to branch off for features, commit everything and then split and merge the commits into logical units and merge once it all looks perfect. That has big advantages for big projects where a lot of people collaborate. I don't think it's worth the overhead here. Show quoted text

> You could have a changelog parser that ignored all non "tagged" commits, > but the automation would break if you missed tagging an entry.

That would be a viable solution as well. I think we'll go with hand-editing the ChangeLog for now, until, which is not likely, it becomes too hard to keep it up to date. -- Lubomir Rintel (Good Data)

Sat Feb 26 14:58:33 2011 JLAVALLEE [...] cpan.org - Taken

Sat Feb 26 17:30:06 2011 JLAVALLEE [...] cpan.org - Status changed from 'open' to 'resolved'

Sat Feb 26 17:30:07 2011 JLAVALLEE [...] cpan.org - Fixed in 0.33 added