New release version number?

[xambroz]

Hello, please would you consider to tag new release version? it is 550+ commits and nearly 4 years since last version release. Thank you Michal Ambroz

[sullo]

I happen to like version 2.1.6 🤣

I have a few open bugs I'd like to fix, but could probably kick out a new version soon.

[NicolasCARPi]

@sullo Please take this advice that I humbly offer: there will ALWAYS be "a few open bugs you'd like to fix", and after a while it gets scary to tag a new release because there have been so much changes from the previous version. This is why one needs to try and release as often as possible, so that fixed code gets to users faster. 5 years is a long time ;)

Thanks for this tool and if you need help with issue triaging and PR reviewing I'll be happy to lend a hand if you give me more rights to the repo!

[digininja]

As author and maintainer of quite a few tools, there is only one that I actively tag releases on and there is a very specific reason for that.

For all of them though, I only offer support on the latest master branch and so deliberately don't do releases because what I'd end up with is support tickets pointing out bugs that had probably already been fixed.

I know I could do a release after each bug fix, but that would just be the releass tracking the master branch, so why not get it from there.

Why do you want a release rather than using the very latest version?

On Mon, 21 Sep 2020, 02:48 Nicolas CARPi, notifications@github.com wrote:

@sullo https://github.com/sullo Please take this advice that I humbly offer: there will ALWAYS be "a few open bugs you'd like to fix", and after a while it gets scary to tag a new release because there have been so much changes from the previous version. This is why one needs to try and release as often as possible, so that fixed code gets to users faster. 5 years is a long time ;)

Thanks for this tool and if you need help with issue triaging and PR reviewing I'll be happy to lend a hand if you give me more rights to the repo!

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/sullo/nikto/issues/590#issuecomment-695869165, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAA4SWMU4WK3CCTHPD3KEJ3SG2WIXANCNFSM4G4VV4BA .

[tautology0]

We do seem to like procrastinating about releasing a new version :-)

[NicolasCARPi]

@digininja It's easier for someone to say "I'm using version X.Y.Z" instead of "commit a23eb94". Also, you have to realize that tags make it reproducible, because it points to a specific commit, so if the software is packaged/distributed, you'll want to use a tagged release, and not point to master, that will change over time and misses the semantic versionning so you don't know when things will break. I do not know of any mature project that do not use tags and version releases.

You're free to do as you like with your projects, but I think the majority of nikto users will agree that it is indeed useful for several reasons to have regular tagged releases.

@tautology0 @sullo You could start be releasing an alpha or beta version, so users have a new version to point to, but at the same time we all agree it might contain bugs and is still a work-in-progress ;)

[digininja]

For debugging, it is easier for me to say "checkout the latest version and try that, if it still doesn't work, we can start debugging" If someone reports a problem in 1.2.3 then we could end up wasting time debugging an issue which was fixed in some newer version.

On Mon, 21 Sep 2020 at 10:28, Nicolas CARPi notifications@github.com wrote:

@digininja https://github.com/digininja It's easier for someone to say "I'm using version X.Y.Z" instead of "commit a23eb94". Also, you have to realize that tags make it reproducible, because it points to a specific commit, so if the software is packaged/distributed, you'll want to use a tagged release, and not point to master, that will change over time and misses the semantic versionning so you don't know when things will break. I do not know of any mature project that do not use tags and version releases.

You're free to do as you like with your projects, but I think the majority of nikto users will agree that it is indeed useful for several reasons to have regular tagged releases.

@tautology0 https://github.com/tautology0 @sullo https://github.com/sullo You could start be releasing an alpha or beta version, so users have a new version to point to, but at the same time we all agree it might contain bugs and is still a work-in-progress ;)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/sullo/nikto/issues/590#issuecomment-696002844, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAA4SWNYBQNVYEQT5C5T32TSG4MCLANCNFSM4G4VV4BA .

[anthraxx]

While I und3erstand your theory behind not releasing, this doesn't work in practice. People are using now a years old version as distros are only shipping releases: https://repology.org/project/nikto/versions

You don't need to support "old" versions and the situation you are in won't change to any worse if you have more recent tags. Just tag semi frequently and you will have relatively fresh versions.

Its pretty much the same for radare2, basically if you come by for a bug you were always told to try git head and come back if it persists, however distros still can ship a quite fresh version.

[drwetter]

One bit from my side: nikto.pl -V doesn't return the git version. (doubt it is actually possible to include something like that).

I would just every couple of months or whenever you feel comfortable increase the last digit. That saves you questions . Alternatively you can also drop the version tag -- it doesn't say anything at the moment other than for whatever reasons Debian-based distros seem to be stuck in a timewarp.

People are using now a years old version as distros are only shipping releases: https://repology.org/project/nikto/versions

That's a good hint for several purposes. Thanks @anthraxx !

[happysalada]

Just adding my 2 cents, I'm looking to maintain this tool on nixos. The latest version is somewhat at a random commit and says it's 2.2.0. having a tagged release helps for maintainers to know what should be released. Since 2.5.0 seems to contain breaking change, the earliest the better IMO (unless there are more breaking changes planned). Having only master valid is a good option too, the best would be that it is explicitely stated. That way maintainers can mark each version as "unstable-2023-11-06" for example.

Finally, thanks a lot for all the work that went into this software! Looking forward to the next version release!

[sullo]

See #727.