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.)
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/
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.
What reasons are there to migrate from vb.net specific language to .net framework language?
Examples:
VB.net
ubound
msgBox
.Net Framework
array.getUpperBound(0)
messageBox
Those functions exist to mirror the built-ins in VB6, to make porting code easier.
The functions in the Microsoft.VisualBasic namespace are often then wrappers around the .Net functions, with some additional checks before calling the function, so there's a minor performance hit using them vs. the native ones.
backward compatibility
VB.Net is a ".net framework language". The examples you showed for .Net work just fine in VB. So, in that sense you would not be migrating from anything. As to why you should prefer the newer .net idioms over the older vb-specific idioms, there are many reasons:
The newer code is more portable
It uses more modern programming concepts, and therefore subtly encourages better habits
The newer code is sometimes faster
The newer code has more features. For example, you can set more styles on the new MessageBox than you can the old MsgBox.
Sometimes neither is the best choice. For example, if you're using arrays much at all in .Net 2.0 and later you're doing something wrong. IEnumerable(Of T) and the various generic collection types are much to be preferred.
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
I'm writing a small free tool. It's currently in Beta testing using .NET 3.5 but there's at least one aspect from .NET 4 I'd like to incorporate.
So, is it jumping the gun a bit to release .NET 4 based software?
Thx!
Wait till atleast the public release of .NET 4.0 before releasing anything other than early beta software with it.
I'm excited about alot of the new stuff too, but beta software built on a framework that is itself in beta is a recipe for disaster if you ask me.
Writing code for 4.0 might make sense. Releasing for general consumption prior to its official release seems foolish to me. Minor changes in 4.0 between now and the official release could cause your code to break. It would likely be easy to fix, but until you do your users are mad at you for putting out (what appears to them to be) a buggy program.
I read somewhere that VS2010 comes with a go-live license, meaning you can. Not sure I would, though. (See other answers...)
Well, you'd be forcing people to download and install Beta software. People may be reluctant or even unable to do this so, if nothing else, you're limiting your audience.
Also anything built with the Beta software isn't guaranteed to be compatible with the final released version.
I wouldn't go for the full framework, but including libraries like the CTP for the Task Parallel Library if your application is heavily multithreaded would be OK since you can just ship the .dll with you application and your users won't have to download anything. However, even with the TPL I would watch out, it's quirky and can slow your algorithms by an order of magnitude on things that should seemingly run just fine. The CTP is already over a year old though.