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.
Related
I'm new to openflow protocol. I think, there are 5 version of openflow protocol available (1.1 to 1.5). Can somebody help me out in understanding or a provide a link which summarizes the difference b/w these versions?
Thanks
You'll need to read the specifications yourself, the official URL is:
https://www.opennetworking.org/sdn-resources/technical-library
Each specification has the historical change logs for all previous versions listed in Appendix B.
Some advice: Start with Openflow 1.0, then read the 1.0.1 errata which clarifies things a bit. Then read the newer versions if you really need to. The newer versions > 1.0 add a lot of complexity which makes them hard to understand if you don't know Openflow 1.0 already.
Personal note: Most publicly available implementations still only support version 1.0, newer ones have recently started to support v.1.3. A lot of research is still being done with v.1.0, so it's not completely obsolete yet. Newer versions are mainly extensions of Openflow 1.0, possibly with some fixes for edge cases and the like.
Other resources: This document by the Open vSwitch maintainers has an overview of some things that changed over time (with tables comparing versions):
"Design Decisions in Openflow"
It may also help to read the Wiki pages and archived discussions leading up to the release of Openflow 1.0 on the previous website (not maintained anymore):
http://archive.openflow.org/wk/index.php/OpenFlow_Releases
Finally, you may want to take a look at a survey paper to get an overview over some of the projects being worked on, e.g. this one:
"Software-Defined Networking: A Comprehensive Survey"
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%.
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.
We are in mid of a project where we have used an extended Dojo 1.1.1 to meet the customer requirement and add richness.
But there are quite some bugs and performance problems with this version of Dojo and
we are looking ahead to migrate the Dojo version to overcome both the issues, but the migration cycle seems to be quite painful and may not be yield expected result.
The concern we have is with the various extension which we have created with the version of Dojo for components that were provided in 1.1.1 and the impact on them after migration.But, the advantage we see are equally important.
As per Dojo , they have kept some level of compatibility with version 1.1.1 but i have not seen any discussion around this anywhere.
Has any body else previously done
migrated between Dojo version?
Will the components like Grid will
work as expected or will i need to
carry out a refactoring exercise?
Do we have any commercial support
available as the forum seems to
deprecated?
Any help or suggestions are welcome
Dojo has had a policy of freezing and supporting public APIs since 1.0. Migrations prior to 1.0 were extremely painful. Now, it should be much better, provided you use only public APIs. Code written for stable JS APIs in Dojo or Dijit in 1.1 should largely still work. Exceptions are noted in the release notes, which you should explore (good luck finding them... unfortunately the site is a bit of a mess)
If you wrote any custom widgets, you're probably in for some extra work. dojox.grid was not particularly stable at that point, and it has also seen a major rewrite since then (there is an old 'compat' layer you may wish to use)
Regarding for forum, like the note says, you can either use the active dojo-interest mailing list or post questions here at SO. There are some firms which offer commercial support, but that's outside of the scope of Dojo as an open source project. (try googling 'Dojo commercial support' or asking on dojo-interest)
I have done 5 dojo migrations now (from 0.2 -> 1.4) over the last few years. Although the API does not change, you will often have coded in workarounds that no longer work after upgrading. Things I have noticed:
quality in 1.4 is VERY good and worth
upgrading to (even from 1.3)
although
the API does not change, little
things that are not public often
change slightly (diji.Tree
itemNodeMap -> itemNodesMap in 1.4)
build options are usually added each
release but not always publicised -
strage really as they are always
useful improvement
since you are 1.1.1, you should change all your set attribute calls to 'attr' - this could take a while to do.
As for commercial support, you could try Sitepen
The ECMA standard for the .NET Common Intermediate Language has been updated three times. I haven't been able to find a version history that would make clear the changes between the versions. Are there any substantial differences between the four, e.g. new opcodes etc.?
Also: Is the same true for MSIL?
Thank you!
Yes, the first two editions didn't have generics - that's by far the biggest change.
The third edition has a list of major changes in the foreword.
I don't know about the differences between 1/2 and 3/4... I suspect those were very minor changes.
(I also don't know whether the ECMA C# spec will ever catch up with the Microsoft version... the current ECMA version is C# 2.0 basically.)