The major reason is that PlantUML is developped with continuous integration in mind. That means that there are new releases quite often, with (hopefully!) backward compatibility.
If the language is usually backward compatibility, it is not the case for the PlantUML Java API itself. The single number versioning schema does not allow to clearly indicated Java API changes.
Furthermore, now that there are a lot of plugins that use PlantUML, we think that it is time to propose a more standard way of versioning PlantUML.
Last official release number 2017.08 was a first move, but it does not follow standard semantic versioning.
Important final notice: You have to understand that there are two different things :
@endumlfor instance) : This part is very stable. We really take care about backward compatibility here. Even diagrams that have been written by earlier versions of PlantUML are still readable by latest releases.
This number will increase when there will be an incompatible change in the Java API.
Also, if ever there is a change in the PlantUML language itself which break ascending compatibility, we will also increase this number, but we expect that this will never happen (it has not since 2009!).
||2017||This number will be the releasing year of the version. While this is not completely standard, we think that it will help people to know whether they are using a recent version of PlantUML or not.|
This number will be simply incremented for each release of the year. We expect about 20 to 30 releases per year.
It will be reset to zero at each year change.
Note that when incrementing the
YEAR will stick the the current year,
RELEASE will be also incremented.
Users are encouraged to give feedback on this doodle to
tell us if we have proposed in the right solution.
HOME NEWS MAP