Inconsistent and missing IPv6 Toolkit version information

[alvarezp]

trafficstars

Hi,

There is inconsistent version information in multiple IPv6 Toolkit sources, and thus, lack of an official versioning and release scheme. This makes it more difficult to identify supported versions in OS distributions as well as identifying newer available IPv6 Toolkit versions, if any.

The following version information is found in official sources:

• The most recent Github repository tag [1] shows the last version to be 1.5.2.
• The most recent README.TXT file [2] as well as the ipv6toolkit.7 manpage [3] still reads 2.0.
• A presentation at the recent Troopers conference [4] references version 3.0.
• The official IPv6 Toolkit Web site [5] shows no reference to a most recent released version or official tarball. I remember there was a reference to a .tar.gz with version information some time ago.

[1] https://github.com/fgont/ipv6toolkit/tags [2] https://github.com/fgont/ipv6toolkit/blob/master/README.TXT [3] https://github.com/fgont/ipv6toolkit/blob/master/manuals/ipv6toolkit.7 [4] https://www.troopers.de/troopers19/agenda/fn3vaw/ [5] https://www.si6networks.com/research/tools/ipv6toolkit/

I see Gentoo moved to a date-based release approach based on version 2.1. I am thinking on doing something similar with Debian. It would be great if a formal versioning and release scheme could be implemented.

Thanks, Octavio.

[alvarezp]

I also found that CHANGES.TXT is showing 2.1. Maybe this would need fixing too.

[alvarezp]

One more: script6 has this line:

$SI6_TOOLKIT="SI6 Networks IPv6 Toolkit v4.0";

[alvarezp]

Finally, I found blackhole6 with this line:

print "SI6 Networks IPv6 Toolkit v2.0 (Guille)\n";

I did a grep and did not find anything else inside the code.

[fgont]

(appologies for beign outside of this planet for the last two years or so)

WIth regards to your feedback (which of course you're absolutely right), how about this:

• Regarding consistency in the version names across multiple files: Not sure how others do this, but I wonder if either:

  • We should simply keep track of which versions embed version numbers, and ensure consistency, or,
  • Keep the version number/release_name in a single file, and e.g. patch the corresponding files (e.g. with sed) as pat of "make"

• Regarding releases: How about setting two release dates per year (e.e., January 1st, and July 1st)? -- Part of this will set expectations, push revisions, etc.

Thoughts?

[alvarezp]

About version consistency: the best way is to use a single source of truth for all version numbers within the code base. Release tags, and tarball names should always match the version number. Sources can be patched as long as original source code files is not touched during the build process. Intermediate file sources can be created, though. I recommend creating a private release script for release procedure consistency.

For numbering, I recommend the Semantic Versioning specification (example: backwards-incompatible changes must increase the major number). I'd recommend continuing with ipv6toolkit 2.2.0.

About release schedule: Any date should do but I recommend having initial stable releases (x.y.0) on late May and at least one bug fix release before October if bugs are reported.

(Edited to change "backwards-compatible" to "backwards-incompatible")

[robert-scheck]

Any chance for some actual progress one or another way?