314
You are completely abusing branches! You should have the customisation powered by flexibility in your application, not flexibility in your version control (which, as you have discovered, is not intended/designed for this sort of use).
For example, make textfield labels come from a text file, not be hardcoded into your application (this is how ...
answered Nov 9 '15 at 16:03
Lightness Races in Orbit
7,8963 gold badges35 silver badges43 bronze badges
152
Use tags to mark commits with version numbers:
git tag -a v2.5 -m 'Version 2.5'
Push tags upstream—this is not done by default:
git push --tags
Then use the describe command:
git describe --tags --long
This gives you a string of the format:
v2.5-0-gdeadbee
^ ^ ^^
| | ||
| | |'-- SHA of HEAD (first seven chars)
| | '-- "g" is for git
| '-...
93
This is a summary of the excellent Wikipedia article about the Java version history. It is highly selective (and biased on what I know and use), otherwise it would simply turn out to be a copy of the article.
The bold parts are what really brought the language forward as a whole. As you see, not every release has bold parts.
Java 11
JSR 384, what's new
...
93
Having 500 clients is a nice problem, if you had spent the time up front to avoid this problem with branches, you may never have been able to remain trading for long enough to get any clients.
Firstly, I hope you charge your clients enough to cover ALL the costs of maintaining their custom versions. I am assuming that clients expect to get new versions ...
84
As you describe it, you already have some sort of version control, though currently there are some issues with it compared to a typical version control:
An intentional commit in version control indicates that the developer strongly believes that the current state of the system would build successfully.
(There are exceptions, as suggested by Jacobm001's ...
69
It means that when you do a commit to the version control system either everything you want to commit goes in, OR nothing does.
In CVS, when you try to commit it's possible for the commit to succeed on several files, then fail on several others (because they've changed). This leaves the repository in an unfortunate state because half of your commit isn't ...
63
Sun Microsystems had back then a bad habit of going through numerous naming changes for its products, and to use confusing name to start with in the first place.
What's in a Name, or what does "Java" Mean?
Originally the term "Java" was being used to describe indiscriminately:
the language,
the platform,
and some others happened to refer to the JVM and ...
50
The problem with using a date, is that specifications are written against the counting numbers rather than a date when it's due.
"This piece of functionality is due to be in release 1. The other piece of functionality is due to be in release 2."
You can't refer to a date in specs, since the release date could get missed.
If you don't have such a formal ...
49
Just my personal view: Version control is useful for anything that takes me more than half a day or that involves a lot of trial and error – or both, of course. If it involves two or more people who are not using the same keyboard and monitor all the time, it is essential.
The cost of using a formal versioning system, beyond the initial learning curve, is ...
45
Your build number won't be reset to 0, when minor and major versions increase, this violates sections 7 and 8 of the specs:
Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards compatible functionality is introduced to the public API. It MUST be incremented if any public API functionality is marked as deprecated. It MAY be incremented if ...
42
This has come up on a few projects for me. The best solution I've had so far is to generate a version number like this:
x.y.<number of commits>.r<git-hash>
Typically, it's generated by our build system using a combination of some static file or tag to get the major revision numbers, git rev-list HEAD | wc -l (which was faster than using git ...
40
In the future, ask the Joel test questions in your interview. You'd be more likely not to walk into a trainwreck.
This is an, ah, how shall we say... really, really bad problem to have. The "interest rate" on this technical debt is going to be very, very high. It might not be recoverable...
How integrated with the "core" are these custom changes? Can you ...
38
Version control was always needed, even before you hacked together your "but, we backup really often!" kludge.
Version control lets you publish those changes across files that belong to a logical function as a unit. If you need to review "what was necessary for case-insensitive sorting in that mask?", it tells you all relevant changes and suppresses the ...
29
You hesitate because you don't want to make semantic versioning, you want to make "advertisement supporting versioning". You expect a version number "2.0" to tell the world that you have a bunch of new cool features in your library now, not that you changed the API. That's ok (many software companies and/or developers do that). IMHO you have the following ...
28
Personally, I choose option 3: keep versioning information in VCS metadata, specifically, tags.
Git makes it very easy to do so, because there is a command git describe, which can uniquely describe a commit based on a tag. Here's how it works:
If the current commit is tagged, output the name of the tag.
Otherwise, walk the history backwards until you find ...
27
Although this approach has benefits as you described, there are certain drawbacks if you use date as a version number:
Date based versions are flat. With v2.1.3 you can see the version number, sub-version number and sub-sub-version number. With 20110119 you can only see when it was written. You could group your date-based versions by month, but it still ...
24
After you release your software, the version number should be incremented immediately.
Why?
Let's assume you're following a scheme like Semantic Versioning, and you have a build number in the version. So you might have [Major].[Minor].[Patch].[Build]. I am going to call the [Major].[Minor].[Patch] part the version.
You will be creating multiple builds ...
24
It makes sense to specify the version you require. Behavior you may rely on could have changed, so newer is not always better. First, test whether a new version of a library works for you. Then, update explicitly.
In the case of web resources, having the version be part of the filename is important in the context of caching. For static resources like jquery....
21
Version numbers are only relevant for releases, since they are a way for external users to identify a specific build of your software. If you're just busy doing development and not releasing each fix individually, then don't worry about incrementing the release number for every fix. It's not relevant to external users and wastes your own time with extra ...
21
It sounds like you are bypassing normal conventions just to avoid process overhead/audits. That... strikes me as concerning.
What you are doing is effectively making an extra version number (your minor PCI digit) somewhat intentionally in order to move your feature/minor version numbers back a place, to no longer trigger your internal audit criteria.
...
20
Semantic Versioning seems to be at conflict with most desktop application numbering. We solved this by handing over "product versioning" to the marketing department, and we maintain completely separate (but logical to us) versions for all the components. A specific product version then becomes a defined collection of compatible components. Maintaining ...
19
The whole confusion stems from the different semantics that MS uses for "Build number" and especially "Revision". The terms just mean different things.
Most people (myself included) use a semantic version numbering scheme where you just get a higher BUILD number whenever you have to make a new build for whatever reason. For us, a hotfix is considered just ...
19
How much (and what kind of) structure you need depends a lot on what you want to be able to do. Figure out what you can't live without, what you want to have, and what you don't care about.
A good example set of decisions might be:
Things we can't live without:
be able to reconstruct any past release at any time
be able to maintain multiple supported ...
19
IMHO version numbers are like product names; important in that they're visible but unimportant in that they're decoration rather than content.
Still the version number, like a product name, carries meaning. And the most important thing you can do is avoid confusion. So here are some common expectations with respect to version numbers. To the extent that ...
18
It's actually Candidate Release.
CR=candidate for release
The use of the CR (Candidate Release) qualifier is for releases that we anticipate can be the GA release, but we need the community to help validate the release. Again, there is an optional numeric qualifier that can be added if there is a need for multiple CR releases. Finally, the use of the ...
17
This is one of the worst anti-patterns you can hit with any VCS.
The correct approach here is to turn the custom code into something driven by configuration, and then each customer can have their own configuration, either hardcoded in a config file, or in a database or some other location. You can enable or disable entire features, customize how responses ...
16
Microsoft describes the purpose of each component of a .NET version number in their MSDN documentation for the Version class. Here is the relevant portion:
major.minor[.build[.revision]]
The components are used by convention as follows:
Major: Assemblies with the same name but different major versions are
not interchangeable. A higher version ...
16
This is something that you are going to have to take a look at from a couple of different angles as you need to take into account user needs as well as the needs of the software and developers.
In general, your customers aren't going to care very much about what the version number of the software is going to be as long as they know they are running ...
15
DirectX added version numbers to its interfaces. In your case, the solution would be something like
public interface IFoo2 : IFoo
{
void Glarg();
}
The API would still refer to IFoo, and to IFoo2 only in methods etc where IFoo2 functionality is required.
API implementation should check in existing (=version 1) methods whether an IFoo parameter object ...
Only top voted, non community-wiki answers of a minimum length are eligible
