versioning of glaze

[arturbac]

Just for Your info.
With 3.5.0 You are making API breakage but not following with this version semantic versioning.
With the approach widely used in semantic ver. it is much easier to manage such packages in projects

MAJOR version when you make incompatible API changes
MINOR version when you add functionality in a backward compatible manner
PATCH version when you make backward compatible bug fixes

So when some package does not change major version number and is following this scheme then You can upgrade it knowing it should work and be backward compat. with the version You are Using currently.
I know it is up to You but this is versioning scheme is comfortable for users. For example You can set some project to use tag 3.* when this rule is maintained and get all bug and security updates without constantly checking project github page.

[stephenberry]

I get this and considered 4.0.0, but Glaze undergoes a lot of breaking API changes because it has such a broad API. Most of these changes don't affect the majority of users, but they are still API breaking changes. I'm trying to reserve major version numbers to the most significant changes and changes that are likely to affect all users. Glaze has lots of breaking changes that don't make sense for major version releases, because it might leave JSON unaffected, but affect the CSV format. It would be more confusing to users of this library to constantly be putting out major versions. Maybe I should follow a different versioning format? I'm not sure. One thing I try to be careful with is to not introduce runtime breaking changes in minor versions, so breaking changes in minor version numbers are always compile time issues that are obvious for users. There is also the issue that bug fixes that change behavior are not technically backwards compatible, so following strict semantic versioning would require major versions for lots of bug fixes.

[stephenberry]

I feel for you. I would recommend dropping support for older versions of Glaze in newer versions of simple_enum. Older projects can stay on old versions of both and they can be upgraded in tandem.

I do see this year's breaking changes as big steps in maturing Glaze. The development of Glaze is faster than a lot of other projects because its releases and features are being actively developed for a particular project. Getting features rapidly implemented is important right now, but will probably become less so in the future.

[arturbac]

I simply CAN NOT do that because glaze breaks so often backward comapt. and I still want to be able to upgrade simple_enum in my projects without huge refactor caused by glaze... So I have to maintain multiple glaze backward compat in simple_enum. I still have project using glaze 2.x as I have no time to upgrade it to glaze 3.1-3.4, glaze 3.5 I even don't consider as it breaks all custom from/to definitions in my projects, simply don't have time for that more often than ~1 per year.

[arturbac]

For clarity i use glaze already in few commercial projects which are stable at production and it is not an option to break their stability and constantly refactor glaze code more often than 1s a year or so.

[stephenberry]

Thanks for sharing your thoughts. I'm going to be making a few more breaking changes in preparation for a 4.0 release by the end of this year. Staying on 3.4.x should be good, as it is a quite stable and tested version.

I realize the to/from changes are painful for custom definitions, but they should be able to be replaced with a few find and replace calls (this has been my experience updating codebases). This change was a couple years in the making, and I finally decided to bite the bullet as it allows significant removal of duplicate code that is generic across formats. And, we're working on more formats in Glaze, such as BSON and Mustache.

[arturbac]

Thanks for sharing plans and this suggestion it helps me a lot with planing upgrades, I was thinking then You can use prerelease and beta feature of github releases. So that maintain Your release activity while at same time giving with beta/prerelease clear information to users which version to use when they want to use some stable/matured version like 2.8.x+ or 3.4.x