Tidy Release Version

[geoffmcl]

For those who have not read the history... there are lots of comments that touch this... like #120... but others...

From very early on we always agreed the first htacg release would be 5.0.0! That has been done! Initially as 5.0.0.RC1 of Jun 30, 2015, to the final 5.0.0 as of Sep 4, 2015.

We thus started the version at 4.9.??, and added the 5 suffix. This was removed as of the 5.0.0 release, as well as changing the name of two include files...

Before that tidy used a date as its version... like "... 2009", and maybe some with git revisions...

That is history.

In various documentation, comments it was (maybe me?) that suggested the next release should be 5.2.0., with a branch, etc...

But that did not happen.

The next release was 5,1,25. A great, stable update to 5.0.0... a drop in replacement... quite well accepted in distros... need more attention to feeds like this...

We are now considering a NEXT release. What should that number be?

From some comments here and there my feeling is 5.2.0! Thus abandoning any odd/even difference, and branch creation suggested, in favour of clearly GitHub TABed release, indicating a bump in the release level, while remaining 100% compatible with the tidy 5 API.

This does not mean there will not be a 5.2.??, multiple releases there after, in between, before the next 5.3, 5.4?, hopefully each representing a step in the evolution of tidy.

This seems to follow the Semantic versioning... including the recent issue-329 branch, which emits version 5.1.32Exp...

The alternative is to just find the next stable master, 5.2.??, and make that the release... That would work, as it did with 5.1.25, but is this the way to go? It seems ok, but not very definitive...

Am open to ideas... but not for too long... that current next release date, Dec ??, approaches...

EDIT: Erroneously use 5.1 when I meant 5.2

[balthisar]

@geoffmcl, I think we flubbed it with 5.1.0 and failed to formally release it. Currently whatever's in master is usually regarded as stable, but not necessarily released until given a strong tag. The package managers that are following our releases are using the tagged versions.

This means the current Tidy release generation isn't 5.0.0 at all; we've already released 5.1.x branch. The most recently release is 5.1.25, that is, 25 patches have been applied.

Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards compatible functionality is introduced to the public API.

We probably should have bumped to 5.2 when we added --skip-nested and --indent-with-tabs, based on the above.

It MUST be incremented if any public API functionality is marked as deprecated.

Similarly when we marked --drop-font-tags with a warning.

It MAY be incremented if substantial new functionality or improvements are introduced within the private code. It MAY include patch level changes. Patch version MUST be reset to 0 when minor version is incremented.

There have been a lot of patch level improvements. Maybe it's time to bump to 5.2.0, and clarify the options we added and dropped?

Then going forward we stick to 5.2.x until we add or deprecate things.

Any thoughts?

[geoffmcl]

@balthisar sorry I wrote 5.1 but meant 5.2, now edited... stupid mistake...

So it seems we agree, the next Release is 5.2.0!

But I am unsure why I am bringing this up now... really 5.1.25 was just 'released' on 2015/11/23, so it is not that urgent...

But to cover some parts of it now... like choosing a candidate.

Version 5.1.32Exp (in issue-329 branch) feels good, after some more testing of this profond change in the parsing of a <tag> followed by a newline, and it is eventually merged to master... maybe at least another few weeks or so, or even Jan, Feb,... that is say 5.1.33++ territory...

Accordingly have updated the 5.2 milestone to January 22, 2016 for now, added a 5.2.x Feb 22,2016, and added a 5.3 March 22, 2016, and will get around to migrating some more issues to them so the percentage stats look right... and get around to closing some that are in release 5.1.25, so the stats for that should read 100% closed...

But another part is to begin to document the steps needed for a release, and maybe designate who will deal with what. This is just an initial list. Those marked with (G) I could/would do -

• Update version.txt (G)
• Update verslog.txt (G)
• Create TAG, create release (G)
• Generate 5.2.0.html for binaries (G)
• Add binaries (G-win/ubu) (B-mac?)
• Add api doc (B?)
• Update web page (G or B?)
• Create 5.2.x milestone (?)
• Other things?

This list needs to be filled out. I have some scripts for the updating of verslog.txt (2), gen. of html (4), add bins (5), which I can share... maybe we add say a meta repo, and these could be added to a scripts folder, or something... These are just for releasing and I do not think should be in tidy source directly, but...

As I have said somewhere, item 4, gen. of the html for the binaries, the release notes, does need some TLC. It is presently a very dry list of the git commit log, with email address obfuscation, and an authors list... at present this is gen. by -

# Get the changes since the last release, from verslog.txt 
$ git log "--decorate=full" "--since=Sat Apr 25 19:20:16 2015 +0200" > ../tempvXX2.log
# get to correct folder and generate say the release 4.9.32.html 
$ emailobs f:\Projects\tempvXX2.log -o 4.9.32.html -a 4.9.32 -i

emailobs is just a perl script, emailobfuscate.pl, that reads the git log file, converts email addresses, and writes a simple html container as the output file, in this case 4.9.32.html... minimal formatting...

But if possible, if someone could collect say a set of points, changes, improvements, issue closed, etc, and this text could be added to the top of this file as a far more succinct release notes... Just an idea...

Note that item 3 fires the tag feed, used by some distributions as a signal for an update, most notably, homebrew(http://brew.sh/)...

But, at this time #329 needs some testing... and maybe do some other fixes, or minor features added...

What about localize or should this be later? As a 5.2.x?

After that 5.2.0 release, maybe some more, other intermediate 5.2.xx, if needed, before 5.3, 5.4 etc... and so on...

This seems good to go?

[balthisar]

It looks like (B) doesn't do very much. @geoffmcl, thanks so much for everything you do!

I wonder if 5.2 is a good place to also start removing a lot of the conditional stuff that's just part of Tidy now. For example at some point accessibility checking was added but to be cautious the build option was left in. Similar for Asian encodings. I think this is all just part of Tidy now, and I'd be happy to comb through the source and scrub out these leftovers.

I'd love to do that same for all of the deprecated stuff, but I think sticking by semantic versions that's just going to have to wait until Tidy 6.0. Seeing --slide-style show up for 10 years, it can finally die.