318
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
8,4553 gold badges36 silver badges43 bronze badges
95
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
...
94
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 ...
65
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
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 ...
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 ...
39
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 ...
30
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 ...
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 ...
27
This depends on how you plan which features go into which release. For example, if any feature that is merged during a certain timeframe will make it into the 2.4 release, then you can use that version number directly.
If you do not know the next version, it would still be reasonable to update the docs immediately, precisely because it's best to keep code ...
26
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 ...
25
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.
...
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....
23
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 ...
23
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 ...
22
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 ...
20
First, it is important to understand and be able to leverage the difference between Commands and Events.
As this question succinctly points out, Commands are things we would like to happen, and Events are things that have already happened. A command does not necessarily result in a significant event in the system, but it usually does. For example, a send ...
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 ...
17
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 ...
17
I can tell you how I do it at work.
We have a continuous integration server that builds, tests, tags and outputs a versioned package. We only proceed to the next stage if the previous one is %100 successful.
Our version looks like this: <Major Version>.<Minor Version>.<Build Number>
Every successful build that has no completed bug fix ...
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
I adapted semantic versioning for desktop or web applications, so in our work we are using:
X.Y.Z
Z is increasing if a release contains just a bug fix, dependencies update or some application internal changes, so no new functionality introduced to user;
Y is increasing if a release contains minor changes in UI or just introduces some new feature, or some ...
15
There is a great deal of value in using version control even as an individual developer and it could be quite a bit simpler than the backup/file copy based system you have now.
Right now, you have the ability to get to older version of the code, but how do you find the version you want?
Just the ability to do a diff between revisions will be very valuable....
14
Assuming that the semantic versioning is used properly, does this indicate that the system is poorly designed since it makes major breaking changes almost every four months?
Not necessarily.
You mentioned in the comments that this is an internal API. Breaking an API is bad, because you break everybody's code. But for an internal API "everybody" is just "...
13
While not being explicit about it, SemVer applies to released packages.
Therefore, if you, as release manager, build a package containing all 3 commits then you only have to increment the version once. If you choose to release them in separate packages then you have to increase the version each time you release.
13
The purpose of branches is to explore one possible avenue of development without risking to break stability of the main branch. They should eventually be merged back at a suitable time, or be discarded if they lead to a dead end. What you have are not so much branches, but much rather 500 forks of the same project and trying to apply the vital changesets to ...
13
What you call single REST APIs might be called REST API's particular set of resources or resources. You also could look at it as REST API's functionalities. Such as any kind of software, the whole package is versioned/updated, not single functionalities or resources.
Your question would make sense in the context where the REST API package's resources are ...
Only top voted, non community-wiki answers of a minimum length are eligible
