* Michael G Schwern <[EMAIL PROTECTED]> [2008-08-21 01:50]:
> is it worth the administrative effort
The administrative effort of all of three commands? (Switch
branch then merge, plus check in – with the usual release
procedure being performed inbetween, prior to check-in.)
> just to keep trunk "
David E. Wheeler wrote:
This all built up over years as I tried to automate away each stupid
distribution packaging mistake I've made in releasing something to
CPAN.
This should be a module. I'd use it.
What about foy's Module::Release?
On Aug 20, 2008, at 14:58, Eric Wilhelm wrote:
Of course, by trying to make it abstract and reusable, I'm just making
unnecessary work for myself because every author with more than 3
modules writes their own kit? At least, that's the impression I get
whenever I mention it.
I don't have one.
On Aug 20, 2008, at 13:37, David Golden wrote:
This all built up over years as I tried to automate away each stupid
distribution packaging mistake I've made in releasing something to
CPAN.
This should be a module. I'd use it.
Best,
David
Aristotle Pagaltzis wrote:
> * Michael G Schwern <[EMAIL PROTECTED]> [2008-08-20 23:05]:
>> This seems to be a subset of the "should the repository contain
>> all the release files?" argument. Should the repo contain just
>> the files which build a release, or should they contain all the
>> files t
# from David Golden
# on Wednesday 20 August 2008 15:10:
>> Of course, by trying to make it abstract and reusable, I'm just
>> making unnecessary work for myself because every author with more
>> than 3 modules writes their own kit? At least, that's the
>> impression I get whenever I mention it.
# from David Golden
# on Wednesday 20 August 2008 14:57:
>>>For me, the tag *is* the release.
>
>I meant that metaphorically.
Yeah, but how metaphorically? If a recursive diff on (e.g.) 'svn export
$tag' and the unpacked tarball produces output, then the tag == the
release.
>No, my repository
On Wed, Aug 20, 2008 at 5:58 PM, Eric Wilhelm
<[EMAIL PROTECTED]> wrote:
> There's a 500 error on the .pl file there.
Removed the ".pl" extension. (sigh)
> Of course, by trying to make it abstract and reusable, I'm just making
> unnecessary work for myself because every author with more than 3
>
# from David Golden
# on Wednesday 20 August 2008 14:26:
>Uh, yeah, sure
>
>http://echo.dagolden.com/scratch/
There's a 500 error on the .pl file there.
>And it's very specific to the way in which I setup my distributions
>and the way in which I've started embedding version numbers into Po
On Wed, Aug 20, 2008 at 5:45 PM, Eric Wilhelm
<[EMAIL PROTECTED]> wrote:
>>For me, the tag *is* the release.
I meant that metaphorically.
> So, you delete everything from the tag which matches MANIFEST.SKIP? My
> checkouts tend to contain files which don't go in the release and my
> releases con
# from David Golden
# on Wednesday 20 August 2008 13:37:
>> I guess it depends on what you think a tag should contain,
>> along with some artifacts of the VCS (e.g. "a tag must be a copy of
>> trunk" sort of thing.)
>
>For me, the tag *is* the release.
So, you delete everything from the tag which
On Wed, Aug 20, 2008 at 4:49 PM, Aristotle Pagaltzis <[EMAIL PROTECTED]> wrote:
> Mind throwing it into some publicly visible spot somewhere so
> people can gawk at it? (I'm deliberately not saying "release it"
> since that would imply polishing it to a degree you probably have
> no desire for.)
U
* Michael G Schwern <[EMAIL PROTECTED]> [2008-08-20 23:05]:
> This seems to be a subset of the "should the repository contain
> all the release files?" argument. Should the repo contain just
> the files which build a release, or should they contain all the
> files that go into a release?
>
> One s
Jeffrey Thalhammer wrote:
> At my current $job, the Perl code is organized into a handful of
> cpan-style distros. We use Module::Build to build each distro, and then
> use CPAN.pm to orchestrate the deployment of the application from a
> local CPAN repository. This all works like a charm.
>
> B
* Jeffrey Thalhammer <[EMAIL PROTECTED]> [2008-08-20 18:45]:
> My colleagues prefer to have the MANIFEST file in the
> repository so they can run distcheck to see what's been added
> or removed before committing some work.
Err. Shouldn’t that be your VCS’s job? Every single one I’ve used
has a `st
* David Golden <[EMAIL PROTECTED]> [2008-08-20 22:40]:
> My release tagging program makes sure the code is checked in
> locally and synchronized to the remote repository, checks that
> the MANIFEST is up to date, checks that the release tag matches
> the version found in the META.yml, checks that t
On Wed, Aug 20, 2008 at 4:16 PM, Eric Wilhelm
<[EMAIL PROTECTED]> wrote:
> Hmm, I guess it depends on what you think a tag should contain, along
> with some artifacts of the VCS (e.g. "a tag must be a copy of trunk"
> sort of thing.)
For me, the tag *is* the release.
My release tagging program ma
# from David Golden
# on Wednesday 20 August 2008 12:23:
>I want it
>checked in, particularly since the META.yml in a release is dependent
>on the particular EU::MM or M::B I had installed on whatever machine I
>happened to be working on at the time I released the code.
Hmm, I guess it depends on
On Wed, Aug 20, 2008 at 02:56:45PM -0400, Ricardo SIGNES wrote:
> In fact, on my latest dists, I only include the MANIFEST as a couresty to
> stupid software that expects it. I don't see any value in having a MANIFEST
> file in the dist, let alone in my repo.
My .zshrc includes the following lin
On Wed, Aug 20, 2008 at 2:55 PM, Eric Wilhelm
<[EMAIL PROTECTED]> wrote:
> Umm, is that for or against storing META.yml in the repo? For me, the
> cost of checking it in is that you continually have to confront the
> regen/diff/commit issues for a file where the differences don't really
> mean any
* Jeffrey Thalhammer <[EMAIL PROTECTED]> [2008-08-20T12:42:49]
> But there is some debate about whether the MANIFEST and other
> metafiles should be put in the source code repository. My gut feeling
> is that MANIFEST is a generated file, therefore it does not go in the
> repository. Instea
# from David Golden
# on Wednesday 20 August 2008 11:27:
>> The reason, for me, is that generating META.yml is almost always
>> predictable
>
>My view:
>
>* META.yml is an evolving spec
>* The build tools are periodically updated to produce the latest
> current spec
> * Storing META.yml in the rep
On Wed, Aug 20, 2008 at 1:53 PM, Eric Wilhelm
<[EMAIL PROTECTED]> wrote:
> The reason, for me, is that generating META.yml is almost always predictable
My view:
* META.yml is an evolving spec
* The build tools are periodically updated to produce the latest current spec
* Storing META.yml in the r
# from David E. Wheeler
# on Wednesday 20 August 2008 10:39:
>+1, although I recently stopped including META.yml, I always want to
>have MANIFEST in the repo.
Same here. The reason, for me, is that generating META.yml is almost
always predictable but generating MANIFEST very often reveals tha
On Aug 20, 2008, at 09:57, David Golden wrote:
Anyway. I am in the "Keep MANIFEST in repo and manually update" camp.
Me, too, usually. I like to have the repository tag for a release
contain exactly the files in the tarball on CPAN. This includes things
like META.yml.
+1, although I recentl
On Wed, Aug 20, 2008 at 12:50 PM, Gabor Szabo <[EMAIL PROTECTED]> wrote:
> I am quite sure this question has the potential of a nice holy war.
Likewise.
> Anyway. I am in the "Keep MANIFEST in repo and manually update" camp.
Me, too, usually. I like to have the repository tag for a release
cont
First of all thanks for Perl::Critic!
I am quite sure this question has the potential of a nice holy war.
Anyway. I am in the "Keep MANIFEST in repo and manually update" camp.
I think MANIFEST is and should be the tool you control what gets in the
distro and the failures and warnings you might ge
Hi everyone-
At my current $job, the Perl code is organized into a handful of cpan-
style distros. We use Module::Build to build each distro, and then
use CPAN.pm to orchestrate the deployment of the application from a
local CPAN repository. This all works like a charm.
But there is some
28 matches
Mail list logo
