I work on Labware LIMS, which has both configuration, and customization via its own programming language and internal code editor, and stores this customization code in database records. (Note, not the source code of the actual application itself, just the customization code a.k.a. LIMS Basic.) Almost everything in LIMS is stored in the database.
We want to investigate the possibility of using source control to protect this code but we don't know much more than the theory of using something like Git. (I have worked as a junior QA and used git but not as a dev and my knowledge is limited!)
Of particular use would be the merging tools, as currently we have to manually merge code in a text editor, if we even notice there is a conflict (checking content between dev and live is time consuming and involves using multiple tools, some of which are 3rd party tools we have developed ourselves, which are hit and miss. I personally find it easiest to cut and paste into a text file and then use Beyond Compare.
There is no notification that the code is different when moving it from dev to live (no deployment as such, you just import an xml file) so we often have things going live that someone was working on unbeknownst to each other. I.e. dev 1 is working on the code in object 1, dev 2 gets a ticket to make a change to object 1, does so and puts their change Live, whatever dev 1 was doing is now also Live in whatever state it was in. (Because we don't always have time to thoroughly check what state each object is in between up to 3 different databases.)
Is it possible to use source control just on the code within the database, but not necessarily the database itself? (We have backups and such for that but its easy for some aspects of the system to get overwritten by multiple devs working on overlapping areas at the same time.)
If anyone reading this has any specific knowledge of LW LIMS, we are referring to the Subroutines mostly, we have versioned Analyses which stands in for source control for the moment and is somewhat effective but no way to control who is doing what on the subroutines other than a comment log at the top. I have tried to find any information on how other teams source control their code in LIMS but to no avail.
The structure of one of these tables can range from as simple as the code just existing in one field as a straight text dump with a few other fields such as changed_on, changed_by and name (Subroutines), or more complex with code relating to one record being sprinkled around in multiple rows on another table entirely (Analyses) but even if it could just deal with the simple scenario to start with that would be great!
TL;DR: Could the contents of the Code field in a database record be treated like a regular code object in other dev environments somehow and source controlled using Git? (And is anyone willing to explain it simply for me to follow?)
As you need to version control table fields of subroutine, but LW LIMS doesn’t have the IDE for version control (such as git, svn etc). So the direct answer is no.
If you really want to do version control for the codes in database, you can create a git repository and only put the codes in git repository. when a file has updated, you can commit & push the changes. And it’s easy to compare the difference between versions.
More detail about git, you can refer git book.
LabWare LIMS has a number of options for version control. You COULD version the Subroutine table by adding a SUBROUTINE.VERSION field to the table, this works the same way as other versioned tables in LabWare where it asks you if you would like to create a new version of the object before saving. There are a few customers I work with that have done this.
Alternatively, (and possibly our more recommended method prior to LEM) there is the Snapshot capability where the system automatically takes a "snapshot" of objects as they are saved - when viewing these you have the ability to view them side by side in a comparison dialogue - it will show < or > for lines which are different.
Another approach is, if you have auditing turned on you are able to view the audit history for changes to specific objects - this includes subroutines.
One other approach is to use configuration packages - this has the ability to record version AND build numbers. Though individual subroutines is probably a bit too granular for it's intended design.
Lastly, since this question was originally posted we have developed a product called LabWare Environment Manager (LEM) which has some good change control functionality built-in.
For more information on the suggestions above, please have a look at the LabWare Technical manual for the version you are on. We also have a mailing list for questions like this to be posted. You might find an answer there. If you have access to our Support webpage you're able to search previous questions that have been asked. I'd also suggest that you get in touch with your Account Manager at LabWare who can help you answer some of your questions.
HTH
My company is developing a system for 10 years. This system has 15 subsystems that are almost independent (they may use same libraries or packages or DBs), and these subsystems are building locally in separate teams, also a main simple system is developed to read subsystem configs and build a page with menu and submenu from configs(with shortcuts). Our company's product is the exe of this main system.
Unfortunately, we do not use a standard version numbers in our company. Now, we decided to force a standard in company, and I found Semantic Versioning a satisfactory standard, but I have some questions in our case:
How would the changes on subsystem version increase the main system version? Often, after even Major changes in a subsystem, the code of main system remains unaffected. I think changes in the main system should shape the version number of that system, but in this case it does not make sense. Is there any solution for versioning of large applications that consist of multiple subsystems?
You gave a link to MAJOR.MINOR.PATCH, and increment the
MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner,
PATCH version when you make backwards-compatible bug fixes
Any change in a subsystem might make the main system incompatable: Too much to keep track of.
Each subsystem should use their own version. In the main system you should have an overview of the dependencies and the own versioning.
You can manage this in different ways. One way would be using Maven and pom.xml files. Another way would be using a config file with the different versions.
Each team can develop their own code independent and assign Semantic versions.
Maybe some day you will put the shared libraries, packages and DBs in a repository and all teams can refer to them with their own pom.xml.
You are flexible this way. You might even want to make a second main system (for top clients or for free accounts?) and can change the pom.xml including/excluding subsystems. The second main system will have its own versioning.
From the SemVer FAQ:
What should I do if I update my own dependencies without changing the public API?
That would be considered compatible since it does not affect the public API. Software that explicitly depends on the same dependencies as your package should have their own dependency specifications and the author will notice any conflicts. Determining whether the change is a patch level or minor level modification depends on whether you updated your dependencies in order to fix a bug or introduce new functionality. I would usually expect additional code for the latter instance, in which case it's obviously a minor level increment.
I would apply this to your scenario as follows: If your main application takes upgrades of its dependent subsystems without having to make major changes in itself, it should increase either the minor or the patch version. You shouldn't need to increment the major version, as its own public API is still considered compatible.
If the main application makes use of new features added to the subsystems, it should be a minor version increase.
Otherwise, it should be a patch version increase.
I think you're on the right track for this - literally treat everything with a SemVer version as it's own thing.
If you need to rebuild an updated linked dependency then at the least it'd be a patch version update - if they're simply soft links (ie, someone can update the subsystem without rebuilding or needing fixes) then it's purely a case of wanting a version number of when it was changed.
Keeping to the SemVer idea, if things cause incompatible changes then pulling the highest change out could make sense. Ie - updating 5 subsystems at the same time, 4 are patch updates, and one a minor - you'd update the minor version of the main system only (and put them all into that single change). Same with major changes etc.
The other similar idea is to drop the changes slightly if the main build is purely an interface on top - any minor or patch changes would only cause a minor on it, and any major subsystem changes would cause a minor - that way you can keep the major for breaking front end changes etc.
Something to bear in mind is that you don't have to follow SemVer perfectly - consistency is the key for something like this - so you could update the patch level for when subsystem changes are merged in, and never reset it, while updating the minor and major versions only for the main system. (There are a couple of open source projects that work this way, I just can't remember which ones off the top of my head).
Not sure if it's any use, but you could look at some of the nodejs packages around and how they update their versions with differing dependency versions - they all include a list of what they use in a package.json file with the version listed in a certain format (ie, exactly x.y.z or >x.y.z etc - https://docs.npmjs.com/files/package.json#dependencies)
I have been struggling with versioning software for a while now.
I'm not talking about a naming convention, I'm talking about how to actually apply a version in a build system all the way through to a release.
I generally use major.minor.maintenance-[release type]
i.e. 1.0.2-rc1
The problem is managing the version number. I've tried many ways (sticking it in a build file, a properties file, a database, etc,etc) but I haven't found anything that really works well.
The closest thing I came up with is using Jira which I documented here:
http://blog.sysbliss.com/uncategorized/release-management-with-atlassian-bamboo-and-jira.html
I'm wondering if anyone has any good ideas about this.
Also, wondering how people handle releasing a version.... i.e. If I release/deploy version 1.0.0-rc1 do bugs found in this release then get logged into 1.0.0 (the next/production release).
Microsoft uses <major>.<minor>.<patch>-<build number> (or a variation).
I like using <major>.<minor>.<buildnumber>
Where I'm working we use the Maven system: artifact[-major-minor-revision][-SNAPSHOT] which allows us to develop "in progress" versions that change at a moments notice (SNAPSHOT) and those which have been formally released. Some examples are:
email-services-1.0.0-SNAPSHOT.jar
email-web-2.3.11.war
crm-2.5.0.ear
If it has SNAPSHOT in it then it hasn't passed the full suite of tests or is just a developer experiment. If it doesn't have SNAPSHOT then it is a release candidate. We maintain a repository of release candidates and the most recent is sent for deployment once the testers are happy with it.
All of this can be managed with a few simple entries in a build file under Maven. See Maven2 tutorial
This is probably a dead post now, but I'll add my two cents anyways. I'm of the opinion that build numbers should mean something to everyone who sees it. So I personally think that this is a good way to name versions:
major.minor.patch.revision - e.g. 1.1.4.2342
Major/minor numbers are pretty self-explanatory. But from the perspective of the 3rd number, it still needs to mean something to the customer. I've released this new version to you, Mr. Customer, but it wasn't worth a new minor number since we just fixed some bugs. So we've incremented the patch number.
The 4th number usually means absolutely NOTHING to the customer, so you might as well make it useful to you and anyone else in your company that sees it. So for us, that number is the SVN revision number. It tells us exactly which revision was responsible for that version so that we can pull it out any any time to recreate it. Branching code obviously achieves this too, but not to 100% certainty.
Also, another advantage with an all-numeric version number is that it easily integrates into nearly every continuous build system.
Anyways, that's my two cents.
+1 on the Jira/Bamboo solution. The only additional information about the build I would include (for my purposes) is the Subversion Release, although the Tagging operation is 80% of what I want.
Manually maintaining the release/version information is a royal pain. Letting JIRA drive it is a great idea.
On the final question, about where bugs/defects get logged and releasing a version:
Defect/Issue is logged against the release where it appears. A defect in 1.0.0-rc1 gets logged against 1.0.0-rc1
JIRA has (or maybe we added) a 'Fix-For' field that would have the planned release, in this case 1.0.0
If the defect/issue is severe enough, it may be necessary to add another 'rc' release.
The release is made when there are no outstanding critical defects/issues and the customer (or management) agrees that any remaining issues can be deferred
The beauty of managing this through JIRA is that adding releases, generating change-logs, etc. is automated fairly well.
We also use <major>.<minor>.<buildnumber> and we manage this with CruiseControl/(.Net) on our build server. And use Wix and CruiseControl Config to manage the Major minor numbers - still increment those by hand - but the build number happens automatically when on the build server. You could set up a rule an increment the major/minor automatically too I believe - we just have like to do that manually so that it takes concious thinking by a dev when it is time to name a particular release level.
Major.Minor.BuildDateNumber.DailyBuildNumber
Major and Minor are set by us, manually incrementing them as we see fit.
BuildDateNumber is the number of months since the project start multiplied by 100, plus the day number of the current month.
DailyBuildNumber is incremented for every build after midnight each day, starting at zero.
E.g. 4th build of release 5.2 on 10 July, where the project started 1 Jan that year, would have version number
5.2.710.3
This is all calculated for us by the Version task in Nant.
This keeps the version numbers unique and also allows us to quickly calculate when an installation was built.
I've always assumed each number delineated by a period represented a single component of the software. If that's true, do they ever represent something different?
How should a version number be structured to start assigning versions to the different builds of my software? As an aside, my software has five distinct components.
In version 1.9.0.1:
1: Major revision (new UI, lots of new features, conceptual change, etc.)
9: Minor revision (maybe a change to a search box, 1 feature added, collection of bug fixes)
0: Bug fix release
1: Build number (if used)—that's why you see the .NET framework using something like 2.0.4.2709
You won't find a lot of apps going down to four levels, 3 is usually sufficient.
There is the Semantic Versioning specification
This is the summary of version 2.0.0:
Given a version number MAJOR.MINOR.PATCH, increment the:
MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.
Additional labels for pre-release and build metadata are available as
extensions to the MAJOR.MINOR.PATCH format.
It can be very arbitrary, and differs from product to product. For example, with the Ubuntu distribution, 8.04 refers to 2008.April
Typically the left most (major) numbers indicate a major release, and the further you go to the right, the smaller the change involved.
major.minor[.maintenance[.build]]
http://en.wikipedia.org/wiki/Software_versioning#Numeric
Numbers can be useful as described by other answers, but consider how they can also be rather meaningless... Sun, you know SUN, java: 1.2, 1.3, 1.4 1.5 or 5 then 6.
In the good old Apple II version numbers Meant Something. Nowadays, people are giving up on version numbers and going with silly names like "Feisty fig" (or something like that) and "hardy heron" and "europa" and "ganymede". Of course this is far less useful because, you're going to run out of moons of jupiter before you stop changing the program, and since there's no obvious ordering you can't tell which is newer.
The more points, the more minor the release. There's no real solid standard beyond that - can mean different things based on what the project maintainers decide on.
WordPress, for example, goes along these lines:
1.6 -> 2.0 -> 2.0.1 -> 2.0.2 -> 2.1 -> 2.1.1 -> 2.2 ...
1.6 to 2.0 would be a big release - features, interface changes, major changes to the APIs, breakage of some 1.6 templates and plugins, etc.
2.0 to 2.0.1 would be a minor release - perhaps fixing a security bug.
2.0.2 to 2.1 would be a significant release - new features, generally.
In version v1.9.0.1:
This is the explicit versioning scheme used when you don't want to use name for the pre-releases or build like -alpha,-beta.
1:Major version which might break the backward compatibility
9:Adding of new features to support you app along with backwards compatibility with previous version.
0:Some minor bug-fixes
1:Build number(Pre-release number)
but nowadays,you won't find such versioning scheme.Do refer Semantic Versioning [semver2.0]
https://semver.org/
Usually its:
MajorVersion.MinorVersion.Revision.Build
Version numbers don't usually represent separate components. For some people/software the numbers are fairly arbitrary. For others, different parts of the version number string do represent different things. For example, some systems increase parts of the version number when a file format changes. So V 1.2.1 is file format compatible with all other V 1.2 versions (1.2.2, 1.2.3, etc.) but not with V 1.3. Ultimately it's up to you what scheme you want to use.
release.major.minor.revision would be my guess.
But it can vary greatly between products.
It depends, but the typical representation is that of major.minor.release.build.
Where:
major is the major release version of your software, think .NET 3.x
minor is the minor release version of your software, think .NET x.5
release is the release of that version, typically bugfixes will increment this
build is a number that denotes the number of builds you have performed.
So for instance, 1.9.0.1, means that it's version 1.9 of your software, following 1.8 and 1.7, etc. where 1.7, 1.8 and 1.9 all in some way typically add small amounts of new features alongside bugfixes. Since it's x.x.0.x, it's the initial release of 1.9, and it's the first build of that version.
You can also find good information on the Wikipedia article on the subject.
Major.Minor.Bugs
(Or some variation on that)
Bugs is usually bug fixes with no new functionality.
Minor is some change that adds new functionality but doesn't change the program in any major way.
Major is a change in the program that either breaks old functionality or is so big that it somehow changes how users should use the program.
Everyone chooses what they want to do with these numbers. I've been tempted to call releases a.b.c since it's rather silly anyway. That being said, what I've seen over the last 25+ years of development tends to work this way. Let's say your version number is 1.2.3.
The "1" indicates a "major" revision. Usually this is an initial release, a large feature set change or a rewrite of significant portions of the code. Once the feature set is determined and at least partially implemented you go to the next number.
The "2" indicates a release within a series. Often we use this position to get caught up on features that didn't make it in the last major release. This position (2) almost always indicates a feature add, usually with bug fixes.
The "3" in most shops indicates a patch release/bug fix. Almost never, at least on the commercial side, does this indicate a significant feature add. If features show up in position 3 then it's probably because someone checked something in before we knew we had to do a bug fix release.
Beyond the "3" position? I have no clue why people do that sort of thing, it just gets more confusing.
Notably some of the OSS out there throws all this out of wack. For example, Trac version 10 is actually 0.10.X.X. I think a lot of folks in the OSS world either lack confidence or just don't want to announce that they have a major release done.
Major.minor.point.build usually. Major and minor are self-explanatory, point is a release for a few minor bugfixes, and build is just a build identifier.
Yup. Major releases add big, new features, may break compatibility or have significantly different dependencies, etc.
Minor releases also add features, but they're smaller, sometimes stripped-down ported versions from beta major release.
If there is a third version number component, it's usually for important bugfixes, and security fixes. If there are more, it really depends so much on product that it's difficult to give general answer.
Generally then number are in the format of version.major.minor.hotfix, not individual internal components. So v1.9.0.1 would be version 1, major release 9 (of v1), minor release (of v1.9) 0, hot fix 1 of (v1.9.0).
From the C# AssemblyInfo.cs file you can see the following:
// Version information for an assembly consists of the following four values:
//
// Major Version
// Minor Version
// Build Number
// Revision
//
/ You can specify all the values or you can default the Build and Revision Numbers
// by using the '*' as shown below:
// [assembly: AssemblyVersion("1.0.*")]
The paradigm of major release.minor release.bug fix is pretty common, I think.
In some enterprise support contracts there is $$$ (or breach of contract liability) associated with how a particular release is designated. A contract, for example, might entitle a customer to some number of major releases in a period of time, or promise that there will be fewer than x number of minor releases in a period, or that support will continue to be available for so many releases. Of course no matter how many words are put in to the contract to explain what a major release is versus a minor release, it is always subjective and there will always be gray areas – leading to the possibility that the software vendor can game the system to beat such contractual provisions.
People don't always recognize the subtle difference between version numbers like 2.1, 2.0.1, or 2.10 - ask a technical support person how many times they've had trouble with this. Developers are detail oriented and familiar with hierarchical structures, so this is a blind spot for us.
If at all possible, expose a simpler version number to your customers.
In the case of a library, the version number tells you about the level of compatibility between two releases, and thus how difficult an upgrade will be.
A bug fix release needs to preserve binary, source, and serialization compatibility.
Minor releases mean different things to different projects, but usually they don't need to preserve source compatibility.
Major version numbers can break all three forms.
I wrote more about the rationale here.
version: v1.9.0.1
where-
. v is abbreviation of version. It varies with company to company depend on nomenclature adopted in his organisation. It may silent in some organisation like 1.9.0.1
. 1 indicates major version, will be updated on Architectural modification in application stacks, infrastructure (platform) or exposed networks interface
. 9 incates minor, will be updated on activity like adding new components like ui, api, database etc; under a specific architecture
. 0 indicates feature, will be updated on any enhancements on existing components (ui, api, database etc)
. 1 indicates build counter across all phase major, minor and feature. It also include hotfixes post production release.
A combination of major, minor, patch, build, security patch, etc.
The first two are major & minor-- the rest will depend on the project, company and sometimes community. In OS's like FreeBSD, you will have 1.9.0.1_number to represent a security patch.
Depends a bit on the language, Delphi and C# for example have different meanings.
Usually, the first two numbers respresent a major and a minor version, i.e. 1.0 for the first real release, 1.1 for some important bugfixes and minor new features, 2.0 for a big new feature release.
The third number can refer to a "really minor" version, or revision. 1.0.1 is just a very small bugfix to 1.0.0 for example. But it can also carry the Revision number from your Source Control System, or an ever-incrementing number that increments with every build. Or a Datestamp.
A little bit more detail here. "officially", in .net, the 4 numbers are "Major.Minor.Build.Revision", whereas in Delphi there are "Major.Minor.Release.Build". I use "Major.Minor.ReallyMinor.SubversionRev" for my versioning.
The first number is typically referred to as the major version number. It's basically used to denote significant changes between builds (i.e. when you add many new features, you increment the major version). Components with differing major versions from the same product probably aren't compatible.
The next number is the minor version number. It can represent some new features, or a number of bug fixes or small architecture changes. Components from the same product which differ by the minor version number may or may not work together and probably shouldn't.
The next is usually called the build number. This may be incremented daily, or with each "released" build, or with each build at all. There may be only small differences between two components who differ by only the build number and typically can work well together.
The final number is usually the revision number. Often times this is used by an automatic build process, or when you're making "one-off" throw-away builds for testing.
When you increment your version numbers is up to you, but they should always increment or stay the same. You can have all components share the same version number, or only increment the version number on changed components.
The version number of a complex piece of software represents the whole package and is independent of the version numbers of the parts. The Gizmo version 3.2.5 might contain Foo version 1.2.0 and Bar version 9.5.4.
When creating version numbers, use them as follows:
First number is main release. If you make significant changes to the user interface or need to break existing interfaces (so that your users will have to change their interface code), you should go to new main version.
Second number should indicate that new features have been added or something works differently internally. (For example the Oracle database might decide to use a different strategy for retrieving data, making most things faster and some things slower.) Existing interfaces should continue working and the user interface should be recognizable.
Version numbering further is up to the person writing the software - Oracle uses five (!) groups, ie. an Oracle version is something like 10.1.3.0.5. From third group down, you should only introduce bugfixes or minor changes in functionality.
the ones that vary less would be the first two, for major.minor, after that it can be anything from build, revision, release, to any custom algorithms (like in some MS products)
Every organization/group has it's own standard. The important thing is that you stick to whatever notation you choose otherwise your customers will be confused. Having said that I've used normally 3 numbers:
x.yz.bbbbb. Where:
x: is the major version (major new features)
y: is the minor version number (small new features, small improvements without UI changes)
z: is the service pack (basically the same as x.y but with some bug fixes
bbbb: is the build number and only really visible from the "about box" with other details for customer support. bbbb is free format and every product can use it's own.
Here is what we use:
First number = Overall system era. Changes every couple of years and typically represents a fundamental change in technology, or client features or both.
Second number = database schema revision. An increment in this number requires a database migration and so is a significant change (or systems replicate and so changing the database structure requires a careful upgrade process). Resets to 0 if the first number changes.
Third number = software only change. This can usually be implemented on a client by client basis as the database schema is unchanged. Resets to zero if the second number changes.
Subversion version number. We populate this automatically on build using the TortoiseSVN tool. This number never resets but continually increments. Using this we can always recreate any version.
This system is serving us well because every number has a clear and important function. I have seen other teams grappling with the major number/minor number question (how big a change is major) and I dont see the benefit to that. If you dont need to track database revisions just go to a 3 or 2 digit version number, and make life easier!
Despite the fact that most of the previous answers give perfectly good explanations for how version numbering could and should be used, there is also another scheme, which I would call the marketing versioning scheme. I'll add this as an answer, because it exists, not because I think it's worth following.
In the marketing versioning scheme, all those technical thoughts and meanings are replaced by bigger is better. The version number of a product is derived from two rules:
bigger (higher) numbers are better than smaller (lower) numbers
our version number should be bigger (higher) than any of the competitors' version numbers
That takes version numbering out of the hands of the technical staff and puts where it belongs (sales and marketing).
However, since technical version still makes sense in a way, the marketing versions are often accompanied under the hood by technical version numbers. They are usually somehow hidden, but can be revealed by some info or about dialog.