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"
Related
Once Kotlin 1.0 is out, what will be the compatibility policy? As a user, I hope Kotlin would keep its compatibility, either in source or binary. Just as serious as Java.
On contrast, Scala is a bad example. Failing to keep its binary compatibility between minor versions drove me away. And I believe a lot of users have left Scala partly because of its compatibility issue. This caused many libraries (including SBT at my time) cannot provide a complete suite of distributions for the whole series of Scala versions. This is just binary compatibility issue. Imagine if source compatibility was broken.
I have decided to use Kotlin in my company's commercial project. So I really need to be sure Kotlin is serious about keeping compatibility, instead of pursuing beauty.
Kotlin isn't out yet (UPD: now it is). Changes to the language are to be expected (even changes that break code and binary compatibility).
With the Beta release the binary format was finalized, so we shouldn't expect changes there anymore (but they might still happen if bugs have to be fixed).
After 1.0 gets released the language and the binary format is supposed to be backwards compatible forever.
Source: http://blog.jetbrains.com/kotlin/2015/11/the-kotlin-language-1-0-beta-is-here/
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'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.
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.)