Regarding versioning. When the versioning policy of FreeMarker was established, we did not know about SemVer yet. Maybe it wasn't even a thing back then. Now we do releases with the same policy for 20+ years, and changing that is also confusing. Like we spring 2.3.xx for a very long time, and if we suddenly step up to 2.4.0, people will expect that it's some big deal.
Another issue is that SemVer is not a good fit for all kind of projects. For example for us the 3rd version number almost always would be 0. (If it's not, then we just had a broken release, so we had to re-release immediately.) Also, in languages, and let's take Python 2 and 3 as an example, the major (1st) version increase means some huge historical cleanup. Also, I do plan to have a 2.4.0, but that will slightly break backward compatibility. I want to get rid of the gae VS normal distinction, and maybe get rid of some really archaic things that almost nobody uses. In the FreeMarke version policy that's exactly what 2nd version number increases are for, and I believe many languages do the same. It's for changes where most users will have to do nothing, except reviewing the log carefully, to see if they are the unlucky. Now, if we call that version 3.0.0, then what's the thing that we already call FM 3 will be called? (Yes, I know, probablz will be never released, but still... the branch exists, the topic exists.) On Mon, Jan 9, 2023 at 6:18 AM David E Jones <d...@dejc.com> wrote: > > > On Jan 6, 2023, at 11:29, Daniel Dekany <ddek...@apache.org> wrote: > > > > Please vote on releasing FreeMarker 2.3.32! > > I tested the update with and without the latest feature version constant, > all my tests pass. > > On a side note, while testing I was looking at the version number and > thinking about semantic versioning. I don’t remember any discussions about > this but there probably have been some. For a release with new features the > minor version number would be bumped (the 2nd number), leaving the final > number as the patch version for bug fixes only. In other words this would > be 2.4.0 because of minor new features (but nothing not backward compatible > so no need to bump the first/major version number). Semantic versioning is > an interesting pattern, not necessary by any means to roughly communicate > what is going on with a new release versus the prior, but is a clear way of > communicating the most important parts of a release (bug fix only? new > features? backward compatible?). This is not related to the vote for this > particular release, just something related to releases that if others are > interested might be worth discussing. > > +1 (binding) > > -David > > -- Best regards, Daniel Dekany
