Closed applemuncy closed 8 years ago
valera-rozuvan
commented
8 years ago @juliena82 We should use the semver methodology. For example, we can have version opencv-demonstrator v3.x.x that uses OpenCV 3, and opencv-demonstrator v2.x.x that uses OpenCV 2.
Also, we should increment the second number in the version only when a new feature is added to the demonstrator (new functionality). Otherwise, only increase the third number (bugfix releases, minor styling, etc.).
juliena82
commented
8 years ago @applemuncy @valera-rozuvan Aggree with semantic versionning, but disagree with keeping the same major revision as OpenCV (the version number of a software should reflect the evolutions of this software, not of its dependencies). Also we must define what we understand by "public API": technically we have not public API, since the demonstrator is not a Library, but an application. So I would suggest the following: we do as defined in semantic versionnning, but, since we have no public API, we do the distinction between Major and Minor revisions on the base of non formal major changes (e.g. major version stays the same until we decide do change just before a binary release with major enhancements for the users).
Is it ok for you?
PS : the first binary version was released as 1.0.2. I propose that the next binary release to be released as 1.1.0.
valera-rozuvan
commented
8 years ago @juliena82 +1
I agree with you fully!
valera-rozuvan
commented
8 years ago Please create a ROadmap.md file in the root of the project, and let's put there several next versions. For each version we need to put down what we want to achieve (new functionality, new features, anything else).
So that we know what we must work on first! Prioritizing is very important!
applemuncy
commented
8 years ago So may the first number in semver could be 24.x.x 30.x.x 31.x.x ? This Application is always going to be tied to openCV isn't it? And for the new person to openCV they are going to need to know easily which version of openCV a particular version of ocvdemo works with.
juliena82
commented
8 years ago @applemuncy Not so sure : I see three types of person (from the point of view of OpenCV dependencies) who may be interested in this software:
In conclusion, provided that we explain clearly the OpenCV version used in the docs (build instructions or about dialog), I think it could be sufficient, isn't it?
valera-rozuvan
commented
8 years ago @juliena82 I think that we shouldn't tie the version of opencv-demonstrator to the version of OpenCV library. We should simply state in the Readme file, that comes with the release, what OpenCV version is used.
applemuncy
commented
8 years ago OK, not a big deal.
Any thoughts about how soom to try working with openCV 3.1 ?
juliena82
commented
8 years ago @applemuncy You can already use OpenCV 3.1: it suffice to install it instead of OpenCV 3.0. Note: Currently, not a single new function of OpenCV 3.0 is used (only functions that were already in OpenCV 2.4)!
@valera-rozuvan +1 Yes exactly ! (in the Readme file, and in the build instructions, and in the about dialog).
shervinemami
commented
8 years ago I agree with Julien's idea of versioning, rather than tieing it to OpenCV versions. As long as it's clearly indicated what version of OpenCV it's based on (including on the download page of opencv-demonstrator), that is all that's needed.
valera-rozuvan
commented
8 years ago @juliena82 Added Roadmap.md file. Please add anything else you want to it.
valera-rozuvan
commented
8 years ago @juliena82 Also, just in case you still didn't find this feature, a release can be marked in GitHub using this interface https://github.com/tsdconseil/opencv-demonstrator/releases . It creates a tag in Git and also makes available nice archive of the source code taken at that particular tag.
See for example releases of FFmpeg project https://github.com/FFmpeg/FFmpeg/releases !
applemuncy
commented
8 years ago Yes, @valera-rozuvan , and my thinking is for Linux people that stumble in here, they need to have a stable as possible release point tagged because the Master is being actively worked and is sometimes unstable. Windows people are most likely going to try out the pri-built binaries.
applemuncy
commented
8 years ago the Roadmap.md has:
released on 21.11.2015
and that's like two weeks before the the initial release so I assume is out of reach.
And by the way, where is the Gold standard of version number stored?
applemuncy
commented
8 years ago OK, answered my own question. ocvdemo\include\ocvdemo.hpp Troubling to me is I see that the version of openCV is hard coded in ocvdemo/data/lang.xml Wouldn't these be better set up as environmental variables in top level Makefile?
I also stumbled into reading ocvdemo/src/ocvdemo-mmi.cc : )
juliena82
commented
8 years ago @applemuncy First, for people needing a stable version, I think the binary version is the right one. Yet, your are right still, because, unfortunately, we not have made any .deb package for Linux (only installer is for Windows)... But soon someone will tackle on this problem... I hope! Second, you are right, and we will of course tag each time we release a binary version. However, it would be useless to tag the initial commit, because at this time I had not written any build instructions, and the Makefiles (for Linux) had not been fixed / improved by you and the other contributors, so this version is difficult to use (at least the source files)... In conclusion, we should make quickly (I would say in a matter of one or max. two months) another (binary) release (this time with the sources tagged), and with a stable software, even if no .deb is available at this time. PS: currently, there are only 2 constants in the code : VMAJ and VMIN. I will add a third one (VPATCH), so as to follow the (adapted) semantic versionning we have agreed on. Yes, the current OpenCV version shouldn't be in lang.xml, you eagle eye ;) Will be fixed too!
juliena82
commented
8 years ago PPS : ocvdemo/src/ocvdemo-mmi.cc contains the GTK code. Not my favorite part too ;)
juliena82
commented
8 years ago @applemuncy PPPS: I saw that you had began to write a new demonstration some days ago. I am really sorry if you have found this difficult because of the, currently, very bad documented API and way to do it. I have began to simplify it, and I will continue soon, and also add a complete example. I hope it is done in several days, and that it will help for creating a demonstration.
valera-rozuvan
commented
8 years ago @applemuncy @juliena82 @shervinemami I believe that we should continue to use master branch for latest development. However, we need to be doing the following things:
PS: Also, it is possible to get a zip file of a specific release. If you go to main GitHub page https://github.com/tsdconseil/opencv-demonstrator, there you will see near the top a tab named releases. Currently we have 0 releases, but this situation will improve in the future = )
juliena82
commented
8 years ago @valera-rozuvan +1 For 1., totally aggree, this the right and usual way to do it. That's what I suggested too earlier: let's focus today on having a stable and (as much as we can) bug-free version (but with at least additionnal functions as described in the roadmap (which needs to be updated ;) )) so that we can make a release soon. For 2., totally aggree too!
valera-rozuvan
commented
8 years ago OK. So - we have decided on how we will handle our road map, and releases. I believe that we can close this issue. Also, from now on, let's move discussion of each upcoming release to a separate issue. I have already started one for the current release = ) Please see issue #50.
@juliena82 If you are OK with this, please close this issue.
I suggest we use tags to both indicate the openCV release target and ocvdemo release number. First two digits 3.0.x indicate openCV-3.0 and the x be our current release snapshot.
And perhaps a branch indicating bleeding edge as in bleeding_edge_3.1 for work supporting openCV-3.1.
And of course eventually adding new features would be much easier if the code is simplified and documented : )