Versioning

[psanxiao]

As library, NavTableForms releases should be versioning and properly tagged. Versioned jar files should be generated and being available to download, including as well a ChangeLog file with special carefull about making notice if there were compatibility break backward

[oandregal]

In case this is useful, check semantic versioning: http://semver.org/

[fpuga]

navtableforms depends on navtable that also depends on gvSIG. But navtableforms depends also on the evolution of the projects that allows improve the library.

There are two main forms to use in release cycle:

• time based: I think that is imposible for use use this strategy
• feature based: maybe we can try but, ...

At the beginning of a project we can estimated the needed improvements but for sure, not all of them, so how we decide which features should be implemented for a new release. Who should make the release, increment the number and write the documentation?

Due to the small rate of changes in the library, i think that the actual way have benefits over other approach. If there is an api change in a commit or pull request it should be specified in the message, if the developer forgets to include it, it will be also forgot in a changelog file.

The actual away, forces, or should forces, the users of the library to make a bit of code review if they want to see the evolution of the project. This moves the efforts from the core developers to the user developers (note that all of us are switching between these roles), and tanking into account that this is a lib used to solve the need of a core developer in a given project i think that put more effort in the user is not a bad practice.

[psanxiao]

I understand your worries about and even I share many of them. Nevertheless, from my humble opinion, the current situation presents a bigger problem.

As core developer I'm glad to develop new features without taking into account any other thing, even backwards compatibility. But as user developer sometimes I would like to kill myself, or better said, to killing my another me -core developer- .

NTForms has changed a lot in barely a year and the true is that updating a six month old project, for example, it's a torture right now.

Having a versioning strategy could avoid this situation since core developers would be forced to be more careful with the backwards compatibility and also with the new features. The develop of a library shouldn't depend on a single project need.

Of course making a release implies time and a extra effort but in the current situation I think this effort would be less than the one that it's neccesary to adapt projects to the continuos changes in NTForms.