You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
(I'm continuing applying patches to the colordiff 1.x series - i.e. the 'backport' branch as presented here on GitHub - and distributing those changes via Debian and via direct *.tar.gz download. I'll author new changes to that branch too, as appropriate.)
However, thinking about whether the colordiff 2.x rewrite has the potential to proceed further, I thought it would be useful to agree on a good approach for what would be suitable, development-wise.
Kirk: I've no idea whether you're still interested in doing this or not, because you've never responded to my email or comments on the subject. If you are interested, however, then the remainder of this post might be helpful.
Bearing in mind that the primary distribution route for colordiff is via Debian, it makes sense to treat the state of Debian Unstable as the environment for which new versions of colordiff should be designed. I refer to Debian Unstable as "Sid" below, which is the standard codename for that branch of Debian. That is:
Features which rely on a newer Perl version than available in Sid should not be included in colordiff
Perl modules which are available "out of the box" in Sid's Perl distribution or which are already Debian-packaged in Sid can be included in colordiff without issue, because they are "guaranteed" to be available in the destination environment.
Perl modules which are not natively Debian-packaged or not included in the base Perl install for Sid should not be used.
SImilarly, the version of such modules as available in Sid should be considered: features available in module versions more recent than Sid should not be used.
To improve cross-distribution compatibility for colordiff outside the Debian family, however, I believe modules should be used sparingly. For minor added functionality, or code simplification, modules should only be used in place of native code if the gain is significant. Any requirement for additional modules will reduce the use of colordiff, since it will become more troublesome to install or to package.
Further info:
The package and module contents of Sid are a moving target, always getting newer. The versions of specific packages and modules can be found by searching the "unstable" distribution via http://www.debian.org/distrib/packages
Specifically, the current version of Perl in Sid can be found at http://packages.debian.org/sid/perl - it's currently 5.14.2 at the time I write this.
The text was updated successfully, but these errors were encountered:
(I'm continuing applying patches to the colordiff 1.x series - i.e. the 'backport' branch as presented here on GitHub - and distributing those changes via Debian and via direct *.tar.gz download. I'll author new changes to that branch too, as appropriate.)
However, thinking about whether the colordiff 2.x rewrite has the potential to proceed further, I thought it would be useful to agree on a good approach for what would be suitable, development-wise.
Kirk: I've no idea whether you're still interested in doing this or not, because you've never responded to my email or comments on the subject. If you are interested, however, then the remainder of this post might be helpful.
Bearing in mind that the primary distribution route for colordiff is via Debian, it makes sense to treat the state of Debian Unstable as the environment for which new versions of colordiff should be designed. I refer to Debian Unstable as "Sid" below, which is the standard codename for that branch of Debian. That is:
Further info:
The text was updated successfully, but these errors were encountered: