Having an argument with my team members on the api difference and versioning I was stucked when it came to struts with four periods i.e. 2.3.4.1 (a bit weird) . I want to know why it has not picked version 2.4 but 2.3.4.1 ?? Where does the api difference cam in?
Apache has guidelines on release numbering:
Minor Releases
Minor releases signify enhancements to a component that do not necessitate a major release. Developers may perform a minor release if the release is at least external-interface-compatible with the previous release.
Point Releases
A point release typically involves simple bug fixes or optimizations that do not introduce new features. Developers may perform a point release if the release is at least interface-compatible with the previous release.
So unless there are new API additions (which I have not looked at) you would not bump up the minor version number.
2.4 would be a "minor release".
2.3.4 (the last point release) only lists internal changes.
2.3.4.1 is not even a "point release", more like a patch, which seems to match the release notes, which say "Struts 2.3.4.1 includes important security fixes."
See this compatibility table for all struts API versions. There is a minor ABI break between 2.3.4 and 2.3.4.1 in the org.apache.struts2.util.TokenHelper class, but overall compatibility is still 99.9%.
Related
We are using webdriverIO version 4 in a quite a few frameworks where I work. While undertaking the review of one of the frameworks, the option of upgrading to version 5 was recommended. However, the framework is not the most straightforward and there will be a lot of manual fixes needed to commands in many places and the time needed for it is just not known.
Hence the question, what is the risk if we don't upgrade webdriverIO at all? Any dependencies stopping successful builds or browser version incompatibilities affecting test execution? And how soon are these likely to be realised.
Any pointers that can enable this review will be great help.
One of the major risks of not updating over the long-term is Node version support dropping. As new versions of Node are released, you'll likely want to upgrade to the latest. However, since older versions of WebdriverIO won't be tested on these new Node versions, there may be incompatibilities between the two.
Apart from that, other drawbacks include:
Missing out on important new features. For example, WebdriverIO v6 includes 'waits' by default now, so you no longer have to include so many "waitFor" commands, and your tests will be less brittle.
Security Updates via dependencies. While not as important, considering tests aren't normally public facing, it's still nice to have the latest features available.
Unable to make feature requests. There's a very low chance that you'd be able to get any new features added to old versions of WDIO, especially v4. This means you'd have to do it all yourself.
Less likely to get help. If something breaks or you're in need of outside help, being on an older version will hinder any help others can provide as they'll be much less experienced with it.
I've upgraded many test suites from 4 -> 5 and while it wasn't the easiest transition, it was also very doable. Unless you have something very complicated going on, I'd put the upgrade at a week tops. It took me about a work day or two to update mine, but it wasn't the most complex code (on purpose).
I am using akka.net v1.3.13 in my application. But it seems Akka.Cluster.Sharding module is still in beta version. Can I use it for production? When I can expect a stable release for this?
We just released Akka.NET v1.3.14 earlier today and that includes some important Akka.Cluster.Sharding fixes - I'd recommend using that version going forward.
Regarding Akka.Cluster.Sharding's fitness for production use - the -beta tag shouldn't alarm you. That's largely due to Akka.DistributedData, one of the two coordination modes for Akka.Cluster.Sharding (the other being Akka.Persistence) not having a stable serialization format. The default storage mode, Akka.Persistence, is used heavily.
Akka.Cluster.Sharding will be leaving beta in Akka.NET v1.4.0, which is actively being worked on and should be released in the next couple of months.
We are still designing how the API versioning should be managed. As of now we have 2 options:
All the versions in the same branch
Disadvantage: All versions might be using the same core libraries which might be affected by a new commit. There is no code freeze on the older versions.
Different branches for each version
Disadvantage: Manging lot of branches might be a nightmare when it comes to maintanence
Is there any other option to do it in a better way or should I have to proceed with one of the above?
I would suggest separate release branches for each API. You can do bug fixes to old versions off of the release branches.
You shouldn't have lots of versions of your API. If this is a web API, then non-breaking changes don't need a new version. If this is a programming language API, then each major release should be a branch, with minor releases as tags or sub-branches off of the release.
I was just looking on nhforge and saw the most recent release of nhibernate 3.0 is the alpha 1 release. Is that the most recent available binaries, or did I miss them?
Also, is nhiberante 3.0 solid enough to use in a production environment. Is anyone currently using 3.0 for development?
I am beginning to develop a new project and was wondering if I should stick to 2.12 or if it safe to move onto 3.0.
Thank for any thoughts.
EDIT -
I just found the following web post - http://www.infoq.com/news/2010/08/NHibernate-3.0 - which contains the following -
"NHibernate has reached version 3.0 Alpha 1, and is “rock solid”, according to Jason Dentler, author of the upcoming book "NHibernate 3 Cookbook" from Packt Publishing, and interviewed by Scott Hanselman. Dentler also said that even if it is an alpha release, NHibernate 3 is already used in production."
NHiberante does not have an instable branch. The code in the trunk is stable, but it is not feature complete until released. There can be issues in new features, but no issues in existing features. You can use the NHiberante trunk in production. Thousands of people do it already, you won't be the first one. The version in the trunk is more stable than the alpha binary release, because it contains bug-fixes. For NHiberante the rule is: The newer, the more stable.
"ready for production" is hard to answer. I suppose since it's alpha, you can simply say "no".
However, I am using it in a small project that is in production with no issues at all. I am quite impressed with the quality and "solid-ness" for an alpha release. Note that I have much of the code using nhibernate covered with integration tests, so my confidence is pretty high.
I'm getting ready to deploy the first release of our software, version 1.0. Once it's out to our customer, inevitably, some bugs will be found. When I fix those bugs though, I'm not sure what "best practice" is for versioning it. When I release the fixes, would that be an entirely new version (in maven), such as 1.01 (or whatever the increment is, 1.1 for example)? Or would it still be 1.0 with some sort of classifier (maybe a date tag)?
Thanks,
Jeff
Wikipedia has a surprisingly thorough discussion of software versioning. It covers all the major points and discusses most of the approaches I've seen.
(In your specific case I'd go with 1.0.1 which would generally be regarded as "an update to 1.0 with no significant feature additions")
You have to change the number in order for maven clients to recognize a newer version in the repository. The change is up to you. I'm sure there's a best practice document somewhere but my company dictates the numbers we use so I've never looked for one.