Skip Menu |
 

This queue is for tickets about the CPAN-Changes CPAN distribution.

Report information
The Basics
Id: 94077
Status: open
Priority: 0/
Queue: CPAN-Changes

People
Owner: Nobody in particular
Requestors: TIMB [...] cpan.org
Cc: ether [...] cpan.org
AdminCc:

Bug Information
Severity: Wishlist
Broken in: (no value)
Fixed in: (no value)



Subject: Does not support POD formatting for section headings
MIME-Version: 1.0
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
Message-ID: <rt-4.0.18-5816-1395398375-294.0-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 723
Download (untitled) / with headers
text/plain 723b
Compare the rendering of these two: https://metacpan.org/changes/distribution/DBIx-Class https://metacpan.org/changes/distribution/DBI Using pod gives us: * formatted headers * ability to link to a header * cross-reference links * standard way to declare encoding * a table of contents * formatting for section body text * and much more - http://perldoc.perl.org/perlpod.html I'm strongly of the opinion that CPAN::Changes::Spec should at least support POD and ideally be layered over POD so POD can provide a document object model for Changes. Backwards compatibility could be supported by translating files in the old format into pod as it's read. While CPAN::Changes doesn't support pod I'm unlikely to use it.
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-5816-1395398375-294.0-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <rt-4.0.18-5816-1395398375-294.0-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-15252-1395400638-42.94077-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 95
A compromise approach would be to allow section headers to have an optional /^=head\d / prefix.
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-15252-1395400638-42.94077-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <rt-4.0.18-5816-1395398375-294.0-0-0 [...] rt.cpan.org> <rt-4.0.18-15252-1395400638-42.94077-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-24382-1395403840-929.94077-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 211
Download (untitled) / with headers
text/plain 211b
On Fri Mar 21 11:17:18 2014, TIMB wrote: Show quoted text
> A compromise approach would be to allow section headers to have an optional /^=head\d / prefix.
I've implemented that in https://github.com/bricas/cpan-changes/pull/21
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-5816-1395398375-294.0-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <rt-4.0.18-5816-1395398375-294.0-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-14399-1395418449-227.94077-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 1047
On Fri Mar 21 06:39:35 2014, TIMB wrote: Show quoted text
> I'm strongly of the opinion that CPAN::Changes::Spec should at least > support POD and ideally be layered over POD so POD can provide a > document object model for Changes.
Honestly, the way most Changes files are written is more like markdown lists than POD, and I think the additional bureaucracy inherent in the POD format would be enough of a net loss from a user POV that I'd absolutely argue against 'ideally' being an accurate statement. I can absolutely see *allowing* POD being important (and your PR looks as simple as I was hoping so seems pretty reasonable) but I think regarding it as a default is unfortunate; if it was that good an idea then I'd've expected to see a lot more uptake of it as an idea already, and CPAN::Changes is here to reflect a rough consensus from stuff that already exists. I would note, however, that I absolutely do love the idea of having some sort of document object model for changes, I just find it hard to reconcile myself to the idea that POD should be it.
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-14399-1395418449-227.94077-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <rt-4.0.18-5816-1395398375-294.0-0-0 [...] rt.cpan.org> <rt-4.0.18-14399-1395418449-227.94077-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-14399-1395419141-998.94077-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 422
Download (untitled) / with headers
text/plain 422b
My feeling here is that the Changes file should be as near to plain text as is possible, with no user-visible markup tokens - so markdown fits the bill (although it might contradict some of the existing CPAN::Changes::Spec elements and so be ruled out anyway), but pod does not -- and keep the pod-formatted document somewhere else, e.g. <mainmodule>::Changes, that actually gets installed as a perldoc (just as DBI does).
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-5816-1395398375-294.0-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <rt-4.0.18-5816-1395398375-294.0-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-6506-1417782781-1760.94077-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 162
Download (untitled) / with headers
text/plain 162b
@TIMB - this ticket has been created because of Test::WriteVariants, Data::Tumbler and maybe DBI ... Any new thoughts - are you convinced by the answers, or not?


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.