n't
> think we should mandate a convention of "Alt::*".
Agree. I believe that conveying intent through the name is imperative
only when the protection of users at install time is too weak – as it
has been in Ingy’s conception of the Alt:: concept.
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
we feel
too great about doing a bit and punting on anything more difficult just
because most other communities barely even try addressing this at all.
With this particular change we’re in a different quantitative breakage
league than usually.
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
t all confident that there are
no unintended consequences.
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
* Aristotle Pagaltzis <pagalt...@gmx.de> [2016-04-18 14:31]:
> FWIW, in case it helps (probably not, but eh), the IETF runs hackathons
> that seem to follow the original meaning of the term as we use it; e.g.:
> https://www.ietf.org/blog/2016/04/ietf-hackathon-getting-
* Neil Bowers [2016-04-09 16:23]:
> There’s a well-established definition for “hackathon” these days, and
> the QAH is not one of those.
FWIW, in case it helps (probably not, but eh), the IETF runs hackathons
that seem to follow the original meaning of the term as we use
” metadata is annoying. But that’s the only way
that it makes sense to separate the data into different files.
[^1]: I don’t like `META.meta`. :-)
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
tly *wants* to change these variables has to fight
the framework for it. So maybe there ought to be a mechanism to request
that they not be restored on context release.
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
would advocate against
retaining the old nomenclature – despite the need to rewrite docs and
some of the tooling (which would be needing adjustment for Git anyhow).
Even with the migration being long past, I still contemplate advocating
a switch to `master` every now and then.
Regards,
--
Aristotle
both
sets of tests. This makes it natural from the maintainer’s perspective.
And if the versions of the plugin need to diverge, from the perspective
of the CPAN index, that transition to separate codebases is invisible.
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
tend toward the latter.
But someone with better instincts for Windows may be able to call this
bunk. Mostly I didn’t want to leave the question warnocked.
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
http://log.perl.org/2014/07/7182014-scheduled-maintenance-moving-day.html
using pure Perl (Moose, for
example), then surely the right thing to is simply refuse to install
on PP systems?
Eg. LMU - you cannot split out LMU::XS for historical reasons.
how come? Is there a technical difficulty with that? What prevents it?
Regards,
--
Aristotle Pagaltzis // http
1½ years old.
The current version is 0.67.
--
Aristotle Pagaltzis // http://plasmasturm.org/
it as a fork), just git-clone it,
change the origin URL in to your existing GH repo, and force-push.)
--
Aristotle Pagaltzis // http://plasmasturm.org/
. There’s a little label saying
“You can clone with HTTPS, SSH, or Subversion” right below the little
box you’re copy-pasting from though. How about trying that?
--
Aristotle Pagaltzis // http://plasmasturm.org/
on the blead branch
and point it at the tip of the new extraction?
--
Aristotle Pagaltzis // http://plasmasturm.org/
16 matches
Mail list logo