When you checkin a file, you can make sure the new version is not the new member revision, for example if the changes are unfinished or untested.
What is the equivalent for adding/dropping a member? Is there a status for a file that says "I'm here, but not officially yet" or somesuch?
Yes there is the option of Update Member Revision (Shortcut: F7)
Basically, if you are checkpointing 1.2 member revision then it will become 1.3 and if you want to make again to 1.1 yes you can.
Please refer to below screenshot:
Related
With go get -u it's possible to update all packages in a Go application that uses go.mod. However, there's a convention in Go that the package name gets updated for a major version when there are breaking changes.
For example "github.com/ahmetb/go-linq" changes in "github.com/ahmetb/go-linq/v2" after an update with breaking changes.
How can I detect if any of the packages I use updated their major version?
This has an open proposal that is on hold.
From that thread you may want to use gomajor and see if it works for you.
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.
I moved from sweetalert2 ^7.32.4 → ^8.11.7, I read the v8.0.0 breaking changes and none of my code directly call one of the impacted functions.
I wonder what is causing this mysterious error: (TypeError: this is undefined)
As reported in the SweetAlert2 release note for version 8.0.0 referenced at the top of the README, this major version release introduced a breaking change in the way the Swal is invoked. In the release note there is also a link to the reason why this breaking change has been introduced.
The changelog is actually including this breaking change under the title "BREAKING CHANGE: remove withNoNewKeyword enhancer". The content of this commit explains:
From now on the recommended way to use SweetAlert2 is:
Swal.fire({...options})
I went to see the new documentation examples, and they are all launching the popup with Swal.fire() when before Swal() alone was valid.
The problem is that if you check CHANGELOG.md for fire you don't see any mentions of that function. But this is a breaking change as it was earlier not mandatory and now is.
Here is the fix for my specific problem.
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.
We have a software that has couple of executables inside. One of the executables is Windows service, and it doesn't change that often, usually we release many updates to the main executable, but the service version is same inside installer.
When service is installed first time or upgraded with newer version, we need to run custom action. We managed to solve first install part, but we don't know how to determine that version we're installing now is newer than one that already exists. Sort of if(newver > oldver) run custom action.
Thank you in advance
- Jack
You can try using the upgrade rules of your package. More details here: How to implement WiX installer upgrade?
Rob Mensching (the second answer in the linked thread) shows an example for upgrade rules. You should first familiarize yourself with the Upgrade table and how upgrade rules work. There isn't an easy answer or a quick fix for this in WiX.
Basically, you should have 2 upgrade rules
the first sets a property when an older version is found
the second sets another property when a newer version is found
After that you can use the older versions property to condition your custom action. For example, if the property is named OLDERVERSIONFOUND the custom action condition can be:
OLDERVERSIONFOUND
or something like
OLDERVERSIONFOUND > "1.0.0"
Your best bet is to store the "service" version somewhere in the registry, search for that registry value during upgrade and run your CA if newver > oldver (and the CA should also update said registry value to newver)
Note that Custom Actions are (generally) an admission of failure. I always try to separate out the configuration portion of setup to a pre-install (for sysadmins doing deployment) or post-install (for interactive installations) step - often a separate executable.
Declarative installations with no custom actions are much more reliable - if you can figure out how to rewrite the service so that your custom action is no longer required, you'll be much better off in the long term (this doesn't help when you're under pressure to release now, but it's something to think of for future releases)