What is an effective way of maintaining the version of my project?
I started in a project, and I want it to look professional. I want to do a version for my project, like 1.0 or something, but I don't know how to maintain it or from where to start.
Is there a criteria for incrementing the version before the decimal or after the decimal point, I think I read somewhere its major or minor changes.
Also, is there an existing software that works on the version of my project automatically depending on the changes I make on my code?
NOTE: I use Code::Blocks
See this for lots of great information about versioning!
You didn't mention which development platform you were using, but most of them support auto-incrementing version numbers, but this is only good to signify different builds, rather than a whole new version.
Here is an article that describes the basics of version control Source Code Control
What I do is to have a four field version number. This is made up of the following:
Major version number (which seldom changes and only with major changes in functionality)
Minor version number (which sometimes changes with large changes in functionality)
Issue number which (changes with minor changes in functionality)
Build number which is incremented every time I do a build
The purpose of this numbering scheme is so that when there is a field issue, I can determine which version of the source code in my repository was used in the specific build that the field site is having a problem. I can also know what test environment I need to set up so far as files, database, and equipment.
The issue number tends to change when I am making a change in the functionality that may impact database schema in a small way, new parameters being added, new functionality requested for a customer. The Minor version number tends to change when the new functionality or the changes for a customer are significant.
The Major number tends to change only when there is something really earth shattering that means that going from the older major version to the newer major version is a significant upgrade effort. Cases where it has changed was when we moved from Windows CE to Windows XP, an operating system change which required some source changes for that. At the same time we went to UNICODE support for Far East Asian languages as well.
The main thing is to provide some way that when you see the complete version number you can know immediately the major functionality that is there and to know what the version primarily supports and does not support.
When a particular field is incremented, the following fields are reset back to one (1). So when going from Rel 2.2.1 to Rel 2.3.0 the first field stays the same, the second field is incremented, the third field is set to zero, and the fourth field (build number) will start with one for the first build. Then as there is a build of Rel 2.3.0 the fourth field (the build number) will be incremented.
And each time I do a build, I keep the build products (the installers) for that build stored on a server along with the build notes for that build describing the changes made for the build. I also will do a branch in my repository (Subversion) so as to make it easy to find the source code for that build.
Related
I have found myself trying to upgrade Apache Superset from version 0.35 to 0.37 or soon 0.38 as is about to get released.
Our version of superset was heavily modified, from code added to the default superset files to creating new one. We are talking about hundreds of files changed with 1 to 1000+ added lines Given this fact the upgrade fails with a lot of conflicts, something that was expected.
I would like to find a way to make the upgrade to the newest version and keep our modifications as well as making the process easier for future upgrades.
So far (until 0.35) we manage to upgrade to the newest version and solve the conflicts but it became more and more difficult.
The modification were from the front-end jsx files to css to python files.
What I tried and failed:
make a patch file using
diff <0.35 files> <our modified 0.35>
and apply the patch to 0.37 but this did not work as the files are very different between versions and the line numbers changed drastically as well as the folder structure is different in the newer versions.
Is there any way to keep our modification separated and make the process easier for future upgrades?
The more you fork and has the main branch evolves, the harder it gets to upgrade, that is simply to be expected when forking software. Given current high velocity and general pace of change in the Superset code base, and the pre-1.0 status of the software, you can pretty safely assume that any work you do in a fork is likely to be fully revisited every time there's a major upgrade.
The way you prevent that is:
extending only the things that were designed to be extended (plugins, extensions, configuration hooks)
contributing your changes back into the main branch
Many of us have learned that the hard way in our careers. The typical realization is that overtime, the progress in the main branch offer much more value than your customization, and upgrading and applying your customization becomes hard or simply impossible. The usual solution is to look into your customization and identify the really important ones, and try to contribute them back so that they can evolve with the software.
Has anyone come up with a good solution for debugging executables between different code versions using git? Basically, I want to be able to generate side-by-side executables between my recent set of commits and an older set of commits, as well as keep track of the relevant code to go with it, without everything overwriting when jumping between the commits.
Currently my method of doing this is to make/compile the current code and rename the executable and whatever code I'm trying to analyze in debugger (gdb in my case). Now, to the old code, I like to checkout a new branch before checking out the older commit because I'm paranoid and it builds the reflog for extra safety and check-pointing (I know it's not really necessary). I checkout old code and run the make file on the older commit. Now I have my side-by-side executables that I can run with gdb. It's all a bit tedious though, especially if a few headers/files have changed (I like to break up my code) and also if I now want to make changes and recompile (I've got tons of references/includes and I basically just have to start the process over again). Anyone have a better method?
I recently had a similar problem when trying to debug/upgrade a library which needed to be properly installed on the system (using make install) and make jumps between last stable and development versions.
Since version 2.6.0 (about three years from now), you now can use
git worktree
It basicaly enables yourself to turn any directory, at any place, into an annex of an official git local repository. It does by filling a .git textfile (instead of the regular subdirectory) at its top level, containing informations that point the original one. On the repository side, this annex is declared as so and a new branch is created.
Consequently, you now have the possibility to perform git checkout onto two different revisions simultaneously (one per working directory). And you may add as many annexes as you need. When you're done, simply delete all useless annexes, then call git worktree prune to make it dismiss everything that no longer exists (you may use git worktree lock to prevent some of them to be deleted if their annex directory is to be unavailable sometimes, with removable devices for instance). This will let you compile two different versions of the same application at the same time.
If, however, you need to retrieve a particular revision of your soft but you can't tell which one before you have compiled it, you may want to use
git bisect run
…instead, which will automatically call a script that tells if a revision is good or bad. It's useful when a compilation is rather long and when the whole search can span over several days.
Here's a link to the documentation page related to git worktree.
I'm losing my mind.
Most of our development systems have MS Visual Studio Professional 2012 and they report a version number of
11.0.50727.26. (As seen in the Programs and Features Control Panel.)
However while running a python/psexec reg query script, we discovered a couple of systems report the version number as
11.0.50727.1
When I run the updater (http://www.microsoft.com/en-us/download/details.aspx?id=39305)
Both versions report they are the current version (we want them all to be the same.)
Does anyone know what the last number in the version number actually means?
We use the C++ compiler, but the other pieces are often installed (and not used).
Additionally from within the VS 2012 interface - About, they all report
Version 11.0.61030.00 Update 4
I would like to be able to check on that programmatically using reg queries.
It looks like the C++ compiler is stored in HKEY_CLASSES_ROOT\Installer\Products\2DF9F6B0548E83946BAE6F3414F3B5FB with a Version that stores the version number as a single DWORD (On my latest updated machine 0b00ee66). This maps to 11.0.61030 if you use the first word as two numbers and the second as one.
Note that this is only based on some simple regedit searching so apologies if it isn't 100% accurate.
On your other question it appears as though the Programs and Features control panel reports the original installed version, not the current version. It could just be different installation methods stamping a different number, the updates should be used to determine the currently installed version.
I've been using libdmtx in a project and looking to update to a newer version, but it seems the project hasn't been updated in well over a year. The last update/version was June, 2011. The Git repository shows that the last commit was August, 2011. Finally, the author's web site, which previously promoted libdmtx, Dragonfly Logic, is dead with a 404 Not Found error.
Is there another data matrix library that can meet this criteria?
Open source
Platform-neutral C/C++ (i.e. can build for Windows, POSIX environments)
Encodes/decodes data matrix
Actively maintained
Alternatively, did libdmtx move somewhere else and continue to get maintained somewhere that I'm not aware of?
I can't say that I'll never develop on libdmtx again, but it certainly wouldn't be anytime soon. I simply don't have the spare hours anymore to even keep up with the correspondence, let alone to perform any meaningful development.
So if you wish to fork it, you have my blessing. :)
Unfortunately I'm not aware of any other open source packages that do exactly the same things as libdmtx (which is why I created it in the first place), but I tried to list any similar projects I came across at http://libdmtx.sourceforge.net/resources.php
Good luck!
As libdmtx is currently unmaintained (I wouldn't say dead, as there are several users of the library) one should have to look at options.
zxing-cpp is a viable alternative. It can code and decode both DataMatrix, QR codes and barcodes. It compiles both on windows and posix, and are open source (Apache 2)
My only complaint about the zxing-cpp library is that is doesn't support dot peen generated data matrix images.
This Github project has revived libdmtx in 2016 with sporadic but ongoing activity since then: https://github.com/dmtx
(I am not affiliated with this project, just wanted to add an update to this question after finding it in a search.)
In my project I am using mapforce to create XSLT transforms. The problem is that mapforce generates different output even after a minor change (different var names, different object sequence etc.)
If I implement some functionality in, say, Project branch 1.2 and other developer adds another functionality in branch 1.3, and we both submit changes to branches 1.2 and 1.3 respectively, there is no way one can just integrate changes (I am using Perforce for version control) to version 1.3, it has to be reimplemented.
Is there anyway I could overcome this? Maybe a version control plug-in in mapforce?
I'm afraid this is just a limitation of code generators. Most just assign new labels (or numbers) as they go along, so depending on where the added code is, everything generated after that point will be changed.
To fix it, the MapForce code generator would have to save the metadata used when generating code, and re-use it the next time you generate code. The generator would have to distinguish new items from those that have just moved, and re-use all existing ones. It might be a major change to their software to do this, depending on how it is currently implemented.
It can't hurt to request/suggest such a feature, and having it would help Altova position Mapforce as more of a production-ready solution, able to support version control of the customer's work.