recentpopularlog in

kme : versioning   18

PEP 440 -- Version Identification and Dependency Specification |
For a given release identifier V.N, the compatible release clause is approximately equivalent to the pair of comparison clauses:

>= V.N, == V.*

This operator MUST NOT be used with a single segment version number such as ~=1.

For example, the following groups of version clauses are equivalent:

~= 2.2
>= 2.2, == 2.*

~= 1.4.5
>= 1.4.5, == 1.4.*
python  pip  semver  packaging  versionpinning  pinning  versioning  dependency  reference  dammitbrain 
october 2019 by kme
git_semver · PyPI
Simple usage
<code class="language-bash">git semver
# 0.1.0

git semver --next-patch
# 0.1.1

git semver --next-minor
# 0.2.0

git semver --next-major
devel  git  semver  versioning  packaging  release  utility  python  helperscript 
june 2019 by kme
Debian Policy Manual v4.1.1.1 -
5.6.12 Version

The version number of a package. The format is: [epoch:]upstream_version[-debian_revision].

The three components here are:

This is a single (generally small) unsigned integer. It may be omitted, in which case zero is assumed. If it is omitted then the upstream_version may not contain any colons.

It is provided to allow mistakes in the version numbers of older versions of a package, and also a package’s previous version numbering schemes, to be left behind.
debian  dpkg  packaging  packagemanagement  versioning  version  specification  reference  solution 
october 2017 by kme
Debian -- Debian Releases
Debian 8 ("jessie") — current stable release
Debian 7 ("wheezy") — obsolete stable release
Debian 6.0 ("squeeze") — obsolete stable release
debian  linux  distro  versioning  releases  dammitbrain 
july 2016 by kme
Twelve Views of Mark Jason Dominus
I released the Text::Template module several years ago, and it was immediately very successful. It's small, simple, fast, and it does a lot of things well. At the time, there were not yet 29 templating systems available on CPAN.

Anyway, the module quickly stabilized. I would get bug reports, and they would turn out to be bugs in the module's users, not in the module; I would get feature requests, and usually it turned out that what the requester wanted was possible, or even easy, without any changes to the module. Since the module was perfect, there was no need to upload new versions of it to CPAN.

But then I started to get disturbing emails. ``Hi, I notice you have not updated Text::Template for nine months. Are you still maintaining it?'' ``Hi, I notice you seem to have stopped work on Text::Template. Have you decided to abandon this approach?'' ``Hi, I was thinking of using Text::Template, but I saw it wasn't being maintained any more, so I decided to use Junk::CrappyTemplate, because I need wanted to be sure of getting support for it.''

I started wondering if maybe the thing to do was to release a new version of Text::Template every month, with no changes, but with an incremented version number. Of course, that's ridiculous. But it seems that people assume that if you don't update the module every month, it must be dead. People seem to think that all software requires new features or frequent bug fixes. Apparently, the idea of software that doesn't get updated because it's finished is inconceivable.

I blame Microsoft.

I'm not sure what to do about this. Larry said that the problem was Perl's poor object model. I disagreed. A better model will help solve the hash key collision problem, but not the undocumented method problem. I suggested that perhaps one solution would be for modules to start including an explicit SUBCLASSING INTERFACE section in their documentation, spelling out just what guarantees the author would make for subclasses.
perl  lisp  programming  slides  versioning  subclassing  npcomplete 
october 2015 by kme

Copy this bookmark:

to read