Open alexandersolovyov opened 5 years ago
Agree, the time has come to declare the versioning rules explicitly. Most people like semantic versioning, so I think that this project's principles should be close to https://semver.org/ . The principles are:
It is OK for contributors to make version changes directly in PRs. Probably, I also should say that my intent is to accept PRs even if they are not ideal or stylish.
@grwlf say> In our case, public API consists of command line arguments, stdout messages, exit codes.
Not. The public API is determined by the contents of the files https://github.com/ierton/xkb-switch/blob/master/src/X11Exception.h and https://github.com/ierton/xkb-switch/blob/master/src/XKeyboard.h. If they do not change, the main version should not be changed.
Exceptions and headers are important for libraries. But in our case it is a command-line utility, noone will link it into anything. Need to think more carefully about that vim-plugin someone contributed long time ago.
PS looks like I have to add the following to the public API list.
extern "C"
{
const char * Xkb_Switch_getXkbLayout( const char * /* unused */ );
const char * Xkb_Switch_setXkbLayout( const char * newgrp );
}
@grwlf say> Exceptions and headers are important for libraries.
https://github.com/ierton/xkb-switch/blob/master/CMakeLists.txt:
14: ADD_LIBRARY(${xkblib} SHARED src/XKbSwitchApi.cpp src/XKeyboard.cpp)
???
@grwlf say> Exceptions and headers are important for libraries.
https://github.com/ierton/xkb-switch/blob/master/CMakeLists.txt:
14: ADD_LIBRARY(${xkblib} SHARED src/XKbSwitchApi.cpp src/XKeyboard.cpp)
???
libxkbswitch.so is an interface to Vim plugins. If this interface changes, minor version also must be changed (middle number).
@alexandersolovyov say> xkblib.so is an interface to Vim plugins.
Not. $(xkblib) == libxkbswitch.so.
Not. $(xkblib) == libxkkbswitch.so.
Sorry for the mistake. Will correct the message.
The point is, we catch all exceptions before exiting to vim and we don't install any headers (and I think I will remove X11exception altogether because throwing strings works just as fine)
Will leave this issue open to use as the information for developers. If You want close it, please first create some "readme file for developers" with information about versioning rules and that everybody is participating in version tracking, and maybe some coding conventions (what C++ version to use, spacing rules, etc.).
I think it's time to define versioning principles for this project. Is version number maintained only by project's owner or contributors must change it themselves? When to change release version, for each successful build or when any issue is closed? When to change minor version? Maybe when an issue closed or only when API is changed? What means the major version?
I propose to include this information into README.