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
Related
We're using rack-test for our Cucumber specs. We've been trying to migrate over to Ruby 3 for a while now and the current issue is that the Cucumber tests crash due to rack-test using both keyword/positional args in their internal methods.
I'm up for patching it myself, but seeing how little activity there is on the repo (including PRs open for weeks/months) I fear that I'd do the work and there would be nobody to patch it.
The only alternatives I see are:
Do the work and pray there will be someone to review/merge the changes
Patch it locally & use the patched version locally from now on (yuck)
Find an alternative solution for rack-test
The last solution seems the best IMO. So, are there any alternatives?
As with all open source software, you have a few options:
Keep using the old software version (i.e. don't use ruby v3.0.0).
Hope that someone else updates the dependencies for you.
Do the update yourself.
Stop using the library.
At the moment, option 1 is totally viable; ruby 2.7 is still actively maintained, and support will probably continue until 2023-03-31. You could do this, simply hoping that option 2 becomes available soon.
The standard practice for option 3 is:
Fork the project, and make the fixes.
Open a pull request to the main repo with your fixes. Hopefully it gets merged.
In the meantime, if you need to be unblocked, reference your forked repo in other projects.
This is clearly more effort, but I wouldn't call it a "yuck" solution; not unless your changes are drastic/introduce compatibility issues with the main project, and the two branches diverge.
As for option 4, as with virtually any library replacement, there's always going to be some trade-off between compatibility/features, but clearly other testing frameworks do exist. It depends how you are actually using it. Your mileage may vary.
In summary, I can't really give an objective answer to such a subjective question, but my advice at the moment would be: If you have time/skill/motivation to update to ruby 3 right now, then fork the dependency and update it. (It's probably not a massive change needed!).
But if you lack the time/skill/motivation to do this, then just stick with ruby 2.7 for now.
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.
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.
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)
I have a set of patch files which was used to patch the Linux 2.6.29 kernel for supporting my custom functionality.
I would like to know if it is possible to use the same patch files to patch my new kernel (linux 2.6.32) for getting the same functionality.
Thanks & Regards,
Sen
The patch is always dependent on the kernel version. How well the patch applies depends on how different the version which it was made for vs. the version it was applied to is. In the best case.
There will be four possibilites:
Neither the file, data structures, or APIs have changed, and the files will just cleanly apply.
The data structures and APIs have not changed, but there were minor changes to the file outside of your patched area. So, patch will work, and give you minor errors indicating the lines were shifted a bit.
Some of the code inside the patched area changed, so the patch will not apply. You will have to manually figure out what these differences are, and possibly apply that section of the patch manually to get it to apply. Patch will fail, and will save a ".rej" file showing the rejected section.
Functional changes have been made to the code, data structures, or APIs have changed. So you will not be able to port the patches without figuring out how the underlying code has changed, and modifying the patches to apply to the new paradigm. Of course, you might not know this is the case, and you may have a patch that applies just fine, but then the kernel crashes - so beware! ;-)
There is no definitive answer here. It heavily depends on the contents of the patch and the code that it touches. If it's the addition of a new module, it'll probably. Get both versions of the kernel and diff the relevant code pieces to see if they have changed much. If your patch is for a piece that haven't changed, you're in luck.
of course you can apply your patches with a new Linux version. At least you can (and should!) try to do so. If you're lucky it works... But it really depends on the patches and how version dependend they are.
Philip