I've just inherited an application written in Groovy (version 1.3.5) and would like to upgrade it to the newest release (version 1.7.5).
I can't seem to find a reference that enumerates the differences in syntax, etc., which I would need to be aware of ... and yes, I looked at http://groovy.codehaus.org
Does anyone know of a good place that lists version changes?
Many thanks,
~Aki
I think your best bet would be to try it and see where your tests fail.
You do have tests right? ;-)
If not, I'd write some, then try the upgrade and fix where needed.
I don't believe there is a single page where you'd find all the changes from one version to another.
You could maybe collate something by going through all the release notes, but it's probably quicker to just try it.
You can find the changes from one version to another by looking at the release notes. However, the release notes only describe the changes from version N to version N + 1. I don't know how many versions there were between 1.3.5 and 1.7.5, but I'd guess at least 10.
To discover all the changes between 1.3.5 and 1.7.5, you'll have to look at the release notes for each release. Starting from this page, you should be able to find them all, here are some links to get you started.
1.7.5
1.7.4
1.6.9
1.6.8
1.5.8
You should be able to get older releases (and their notes) from the distribution archive.
Having said all that, reading release notes doesn't guarantee anything, (though it's a good way to learn about new features). The only way to be sure that your code runs under the newest version is to compile and test it under that version.
Related
I have a code running in Node 9.8
Node 9 will reach End-of-life soon.
If I switch to node 10, how can I check if my code will run in node 10 without having to execute all paths of the code ?
Or if I go down to 8.11, how can I check if my code will run in node 8.11 ?
There is no test cases written on the code.
This is a good example of why solid unit/integration tests are critical to long-term maintainability. That said, there are a few steps you can take to reduce the risk of breaking things:
Take a look at the change logs pertaining to the versions you're moving to/from. The NodeJS team kindly includes a Notable Changes section in each change log, though I wouldn't rely on that alone as being 100% inclusive of the potentially breaking changes you may be up against.
Consider writing unit/integration tests, both as part of your assurance that things won't break from this version change, as well as that things won't break from later version changes (or everyday changes for that matter).
As much as I hate to say it, Googling around for guides on upgrading (or downgrading?) NodeJS versions may help you identify potential danger zones.
Generally, I'd consider it safer and better practice to upgrade the version than downgrade. For one, you're moving forward to the newer and greater experience the NodeJS team wants you work with, and secondly, future versions are probably more likely to be backwards compatible, whereas the old version may be missing features you're using.
The rules for when to increase the MAJOR vs the MINOR version number with SemVer 2.0 are very compelling. They clearly give a lot of advantages to knowing if the app/service is backwards compatible.
But the site does not really give an reason for the differences between a MINOR and what it calls a PATCH. I don't see it giving the same benefits of MAJOR vs MINOR.
For reference here are the SemVer rules:
MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.
So the only difference between MINOR and PATCH is features vs bug fixes. My company wants to do that differently.
They want to have MINOR be a collection of [backwards compatible] features. "PATCH" (which we call Incremental) be the releases needed to get those features out. (We release bug fixes as we release features.)
For example, if we plan for 7 [backwards compatible] features in our 2.4 release then 2.4.0 may have 2 of the features, 2.4.1 would have 3 more features and 2.4.2 would have the last 2 (perhaps with a bug fix or two in each release).
I can see that this violates SemVer, but I need to know why SemVer has decided to be prescriptive on the differences between the MINOR and PATCH versions so I can know which way to push my company.
NOTE: I hope that this is not too subjective for Stack Overflow. I don't usually ask questions like this, so it is possible that this question will need to be closed...
The standard is deliberately terse. There's nothing in it that prevents you from releasing a bunch of bug fixes along with your new features and you only have to bump the minor field when you do this. If the changes only involve bug fixes, refactoring or documentation that does not add, remove or modify any interface, then you only bump the patch. The whole point is to communicate to your consumers, their level of risk when taking an update from you.
EDIT:
It is a best practice to separate bug fixes (patches) from feature work (minor) and breaking changes (major), into separate releases. This allows your consumers to automatically pick up the latest fixes, without having to deal with feature bloat or breaking changes.
For example, if we plan for 7 [backwards compatible] features in our 2.4 release then 2.4.0 may have 2 of the features, 2.4.1 would have 3 more features and 2.4.2 would have the last 2 (perhaps with a bug fix or two in each release).
Nothing stops you following SemVer convention and release 2.4.0 with 2 features, 2.5.0 with 3 more features and 2.6.0 with last 2 features and a few bug fixes for previously released features.
It is better to follow some common convention instead of reinventing the wheel. You save time thinking, discussing and documenting a custom solution as well as avoid confusion within the team and newcomers.
https://semver.org/
The Semantic Versioning Specification (SemVer) defines:
Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.
So starting with 1.0.0 is considered stable.
When starting a project normally version 0.1.0 is used and gradually increased, there is a point where the project can have something like 0.20.3 for months/years and it is "stable".
Therefore would like to know what could be considered good practices to follow besides the criteria, arguments before bumping a project to server 1.0.0.
How you are dealing with this?
If there are not issues/code activity in 3 months the version is dumped?
The development team decides when they have version 1.0.0. It is possible for a project to remain in experimental/prototype mode for very long periods of time. The only thing that matters here is whether the interface and implementation can be considered complete or not. What are your goals? Do you have all the planned v1 features in place? Do you have doubts w.r.t. implementation conformance to the documented interface?
Some teams don't have workflows that map onto the full semver spec, but they use packaging/release tooling that requires a semver version string. In order to be legal, they never release version 1.0.0, so any version bumps literally don't have full SemVer semantics. See #4 in the spec.
When I see SomeLib.0.20.3.pkg I assume it is not stable. A breaking change can occur on the very next minor field bump, whether or not there have ever been any such changes in the past. SemVer is a contract that allows the SomeLib developers to break things without notice in this particular case.
There is nothing in the spec that precludes a team from issuing a 1.0.0 and then returning to a long sequence of 0.x.x releases if they so desire to operate that way. This is similar to, but not exactly the same as using prerelease tags. When you issue 1.0.1-prerelease you are at least implying intent to release a work derived from 1.0.0 that is a bug-fix, but the prerelease tag is warning label that you are not yet certain of the safety of the changes you made. Following on from 1.0.0 to a sequence of 0.x.x releases says you might not even be deriving from 1.0.0 anymore. Basically, all bets are off again.
If you require any further elucidation on this matter, please ask, I am happy to try to answer any questions regarding SemVer.
I have a website I'm developing. I try to use SEMVER with any changes I make. Sometimes I'm not sure when I need to bump up the minor version. For example,
I have my website/app at v0.9.0. I have this deployed on a production site. One day, I decide to add some new functionality to the website. I add my new functionality, test it and deploy it and it works great. Since this is not a bug fix, does that mean I need to go from v0.9.0 to v1.0.0? So essentially, if I'm at vX.0.0, it only takes 10 new features to be independently added (no matter the size) in order to go to version X+1 ?
It seems like there should be some way to incrementally increase the minor version. I see a lot of people do v0.10.0 as the next version.
Is that the recommended way to do it?
No Jake, it does not mean you need to go to version 1.0.0. The next minor version after version 0.9.0 would be 0.10.0.
See https://docs.npmjs.com/getting-started/semantic-versioning for a nice intro.
Appreciate if anyone could guide me on how to upgrade couchdb 1.3 to 1.5? I've tried out upgrading the couchdb software and pointing the data directory to 1.3 versions' data directory location, which works fine so far. But is it the best and accurate way of doing it?
Thanks in advance.
Yup, that's the right way.
Here's quote from CouchDB
CouchDB uses semantic versioning, so, in a nutshell:
•X.Y.Z equates to major version, minor version, and patch version.
•The major version will be incremented every time we make backwards incompatible changes.
•The minor version will be incremented every time we add backwards compatible features.
•The patch version will be incremented every time we add backwards compatible fixes.