I have a utility service x which is in maven repo and is used by some of my other services. We normally update the minor version of the service x when we make small changes and we are currently on version 1.0.15.
No I am making another change and I was thinking whether I should update version to 1.0.16 or I should update the version like 1.1.0.
If anyone can provide an explanation on how this should be done in general, that would I am sure help other developers as well as me. Please let me know if you need further information.
Different projects follow different standards on this, so follow what the repository has done to date.
A well-regarded standard for this is called Semantic Versioning (https://semver.org/). If you are starting a new project or there isn't a standard already in place, I would recommend using this.
Semantic Versions are in the format: MAJOR.MINOR.PATCH.
If you have fixed a bug: increase the patch version
If you have introduced new functionality in a non-breaking way: increase the minor version (and reset patch to 0)
If you have introduced breaking changes: increase the major version (and reset the patch and minor version to 0).
If you are unsure whether your change is a breaking change or not - consider your package (or API) from its consumers' perspectives. If their code has to change as a result of your change then it's a breaking change.
Related
I added a single method definition in a interface and I am getting a baseline error with a suggestion asking me for a major version change. I want to ask how does it calculate whether a major or minor change is required? adding one line method declaration shouldn't be a major change, right?
Is there a way to tell it to ignore this particular method declaration?
A new method in an interface means that none of the current implementors are compatible with this version of the interface. Before they become compatible again they will have to implement the new method, thus the version bump is justified. Don't game around it, combine it with more changes or just accept that the bundle version of volatile bundles increases quicker than your version stamp on the fully packaged software.
There's nothing bad to version bumps
I'm using Yarn and when I installed my packages, I wanted to update them. I am really new to this so I having trouble understand what each one meaning.
An explanation would be helpful as I am not getting it from Googling.
(I am using this to install and working with SPFx).
yarn outdated v1.17.3 outdated
info Color legend :
"<red>" : Major Update backward-incompatible updates
"<yellow>" : Minor Update backward-compatible features
"<green>" : Patch Update backward-compatible bug fixes
Edit: - Finally think I understand..
red = Major Update. The updates are NOT backward-compatible.
yellow = Minor Update. The updates have backward-compatible features.
green = Patch Update. The updates are just patches to fix bugs, and are backward-compatible.
Please correct if wrong.
You are quite correct. NPM packages use Semver (Semantic Versioning) to indicate a package version. The version number isn't merely just an incremented number, it tells you a bit about what happened with an upgrade.
So you will most of the time have a version numbers that look like 1.2.3 or (MAJOR.MINOR.PATCH), where:
MAJOR - Big changes that changes the way the package is used, so you might need to update how you use/call the corresponding package. The update is thus not backward compatible.
MINOR - New functionality was added to the corresponding package, your code doesn't have to change. The change is backward compatible.
PATCH - No features were added, patches normally include bug fixes or small optimisations to a package.
Sometimes there is more meta data in the version number, for example 1.0.0-rc.1
indicates that this is a Release Candidate. Other examples include 1.0.0-alpha or 1.0.0-beta.
You can read more on Semantic Versioning at https://semver.org/
Let's say you have a bunch of code and let's assume that you have a first working version. This is version 1.0. You go to your git repository and tag the version. Then in that exact moment you have your first tag or release. Then you have in your code version number 1.0 and in your repository tag number 1.0.
My question is, when exactly do you change the version number in the code to version 1.1 (let's assume we don't care about 1.0.1):
A) do you change it right away after the tag 1.0 is done? Therefore all your code from this moment on belongs to version 1.1. This version "ends" when you create a new tag 1.1, which is the stable version 1.1 and change to version 1.2 in the code.
B) do you change it after you have done several code changes and publish your second tag (tag 1.1)? In that case you have a tag version 1.0 of the stable code and you are making improvements in the code. All new changes you do belong to version 1.0. Then when you are finished making changes, you change the code number to 1.1 and the tag number to 1.1
Nerdy question right ;-)
This is somewhat subjective but I would strongly suggest A. Branch out at a the time of release and start working in a new branch.
It's because your users are then in sync with where you left off in v1. If you introduce a number of features for the working v1.1 branch and possibly some design changes which kind of strongly branch away from v1, you can always come back to what the users are seeing by updating to the v1 branch.
Branching in this way based on release is useful as "checkpoints" based on what the users actually have, not based on what you intend to deliver. This way when a user reports something, you can easily know which version of the code they're actually using and quickly flick to it.
This also leaves some breathing room to do easy "service patches", like a v1.01. I know you wrote that you don't care about that, but if your users report an issue in v1 that you've already kind of solved in v1.1 or the v1.1 design has changed in a way to make it no longer valid, but you want to sneak some patch in between there, you can update to your v1 branch, make a minor tweak, and release a v1.01 service patch kind of thing. There's a bit more wiggle room there for that kind of thing.
As a hypothetical, imagine a user reports a glitch in v1. You can't reproduce it in your latest development branch. Now does the fact that you can't reproduce it in your current changeset mean it's fixed, or that you simply can't reproduce it? The easiest way to know for sure is to be able to quickly switch and use the same version you released to the user. That's where branching off and kind of freezing the branch at the time of release is useful.
Of course you could do that without branching or tagging at all if you just comment your changesets in a way such that you know which one is which. But then there's little point to tagging/branching in the context of a release. If you do it as an organizational means and a way of isolating changesets to one place, I'd suggest doing it in a way that keeps those branches in sync with what the users actually have.
Still learning gradle here. Looking for a way to get either the latest "anything" (snapshot/integration or release) or latest must-be-release for a given range, say [1.0,2.0). Is there a way to specify that? Searched everywhere and only found references to either using ranges (which does not seem to allow me to restrict to releases or work with snapshots) or to always keep it entirely open using "latest.integration" and/or "latest.release".
Please help!
[1.0,2.0) already means either "latest anything" or "latest must-be-release" (I think the latter, but not entirely sure). The other isn't currently supported.
OK, I just updated to the newest Gradle 2.1. That resolved some issues I was having. Otherwise, I discovered the following:
"latest.integration" will match the latest anything - snapshot or release, whatever it finds newer.
"latest.release" will match the latest release and skip the snapshots.
"major.minor.+" (however many version number segments you have) will actually behave as "latest.integration" restricted to major.minor. Originally I thought it was restricted to releases but, no, it actually matches snapshots too.
"[1.0,2.0)" will actually behave list "latest.integration" within the range, too and will include snapshots, unlike I thought and commented above.
So, what I now don't know how to do is how to restrict a range or "1.+" to releases, but that is not my immediate problem (may be some hours from now, LOL).
UPDATE
One way to restrict versions to a range seems to be to mess with "Component metadata rules". Non-matching versions (those outside range) could be artificially declared non-releases. This is really ugly, though...
UPDATE 2
A part of my confusion was due to behavioural change between the old Gradle I was using and the new 2.1 one. Above is for 2.1 - old one I had (1.8) did NOT behave cleanly as per above.
i want to port my application to CodeIgniter but i am wondering whether i should use their v2.0 or v1.72 (then when they release 2.0, upgrade it).
i have never used a framework before so i don't exactly know what implies when upgrading a framework: what does it mean practically - i just move the folders and it will work? or do i have to change a lot of settings, file structure etc? could someone enlighten me about the upgrade process.
and what would you use: v.1.72 or v2.0?
if i'm using the latest version, is there a good documentation for it somewhere so you can read about how to use the new features: packages, drivers and so on.
thanks
You can read about some of the changes in 2.0 here.
I would image the upgrade process should be straightforward as long as you do not use any features that are different/removed such as plugins. Just take your models, controllers, etc and drop them into the 2.0 framework. Then regression test you whole app, fixing any problems as you see them...
If you are selling this app or making something mission critical then of course v1.7.2 is the best choice. That said I have PyroCMS running on v2.0 and since some of my bug-fixes were merged it seems stable enough.
One should consider time frames for deployment:
If it is one week, then stick to v1.7.2
If it is three months, go with v2
Assuming three months is approximately to time for a release to stabilise?