Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What versioning are we use #37

Open
alexandersolovyov opened this issue Jul 20, 2019 · 9 comments
Open

What versioning are we use #37

alexandersolovyov opened this issue Jul 20, 2019 · 9 comments

Comments

@alexandersolovyov
Copy link
Contributor

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.

@sergei-mironov
Copy link
Owner

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:

  1. We don't want changes in major version normally.
  2. We change minor version when public API changes. In our case, public API consists of command line arguments, stdout messages, exit codes.
  3. We change patch version when code changes, nothing wrong with it.

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.

@zvezdochiot
Copy link
Contributor

zvezdochiot commented Jul 21, 2019

@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.

@sergei-mironov
Copy link
Owner

sergei-mironov commented Jul 21, 2019

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 );
}

@zvezdochiot
Copy link
Contributor

@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)

???

@alexandersolovyov
Copy link
Contributor Author

alexandersolovyov commented Jul 21, 2019

@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).

@zvezdochiot
Copy link
Contributor

zvezdochiot commented Jul 21, 2019

@alexandersolovyov say> xkblib.so is an interface to Vim plugins.

Not. $(xkblib) == libxkbswitch.so.

@alexandersolovyov
Copy link
Contributor Author

alexandersolovyov commented Jul 21, 2019

Not. $(xkblib) == libxkkbswitch.so.

Sorry for the mistake. Will correct the message.

@sergei-mironov
Copy link
Owner

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)

@alexandersolovyov
Copy link
Contributor Author

alexandersolovyov commented Jul 23, 2019

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.).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants