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.
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).
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 recently asked a question on updating programming packages (on systems that provide programmer tools via packages) for which there has been no response. This leads me to ask the following question. As a software developer over the years, I've encountered enough bugs in tools that lead me to want to keep at the most recent stable release/update. The important caveat being that near the release date of a component, only clearly necessary changes are introduced. I would like to get a better understanding of the spectrum of how developers deal with new releases to the tools they use. So what do YOU do? Monitor mail lists and update to new releases after careful analysis or on a whim? Take whatever releases project management provides/permits? Out of desperation in response to a gnarly bug you're trying to fix? Something else entirely?
I would like to get a better understanding of the spectrum of how developers deal with new releases to the tools they use. So what do YOU do?
I grab the final release of the new tools as soon as it's available. That is in my private environment.
At work there is often just one specific version which is bought and expected to be used for several years. Developers cannot influence that.
At home I develop in Xcode. I maintain at least 2 versions of the environment, the current official release and the latest beta release. Both versions are kept up to date. If there are any issues with any of my projects and a new release of Xcode, I fix the issues with my project. Under no circumstances will I keep an older environment around for compatibility reasons. Most of my development is done against the stable API unless I need a feature from the beta API. All testing is done in both environments, so that hopefully I'll be able to catch bugs related to API changes as soon as possible. I don't know if I should credit my mad development skills or the quality of Apple's releases, but I rarely encounter any issues with API/SDK changes.
At work I develop in Visual Studio 2005 / Windows XP. It's horrible and there's nothing we can do about it.
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.
I use Intellij Idea 7 for Java dev. My dev is 'limited' to all J2SE features plus light JSP, Servlets, and super light usage of JPA. No J2EE, no massive use of random frameworks, etc.
Is it worth upgrading to ver 8? "Worth it" to me means better "core functionality" in terms of speed (ESPECIALLY startup speed), memory utilization (seems like it starts having serious problems with four or more projects open), and auto bug-finding.
More frameworks supported and more languages supported (other than perhaps Haskell and C++), and more refactorings don't interest me at this time.
A while back, I installed a preview version of 8 and it seemed -exactly- the same as 7, as far as my needs were concerned.
Anyone loving the upgrade to 8, and if so, why?
Thanks
It also seems to be easier to configure a new project over top of a complex collection of existing code.
For example, something that you would naturally configure into 5 or more modules.
There is a really beautiful go to/create test wizard that is bound to ctrl-shift-T. Worth the upgrade by itself
The best way to tell is to check out the list of new features and decide for yourself. I haven't discovered any single feature so far that by itself is worth upgrading - the simplified UML view is quite nice, as is the improved Maven integration. The UI feels a bit more streamlined and faster. It seems like most of the attention has gone into non-Java features like better Flex support (which I am really thankful for as I don't like FlexBuilder but I haven't had a chance to use yet).
IntelliJ 8 has a configure plugins feature that allows you to disable plugins with dependencies. Nothing trial and error couldn't replicate, but it is nice.
Startup is only marginally slower. But indexing once opened is a lot faster than before, even unnoticeable for most projects, except after a commit to Subversion. It seems a commit to subversion triggers the indexing twice.
I am working on the Diana-EAP build - but 8 has git integration built in. The EAP has better git integration than the 8.0.1 release - it looks like that is something they are really focusing on.
Definitely not! Seems that the variables defined in our custom taglibs are no longer able to be used in the jsp (worked in 7.0.4). All red. No auto complete.
Oh, and the new settings menu is horrendous!
Some benefits of IntelliJ IDEA 8:
IDEA 8 supports Subversion 1.5 new functionality - e.g. merge tracking, which may be useful especially if your team (like ours) uses a lot of development branches and thus merging is frequent.
One detail I appreciated about IDEA 8: As you probably know, IDEA has had changelists for pretty long now, built on top of any underlying version control system - this is a really useful feature. So, now that Subversion itself supports changeslists, IDEA's changelist implementation has been changed so that it is perfectly compatible with Subversion's native changeslists. (For example, you'll be able to work with any changelists created in IDEA also when using svn command line tools directly.)
Edit: in your case, perhaps it is not worthwhile to upgrade. For me, at least, startup and file indexing seems to be somewhat slower in 8 than 7. [But for me personally the upgrade was definitely worth it, because it solved a long-standing VCS problem with IDEA 7 - it could hang "waiting for VCS sync to finish" for an hour or whatever after hitting Ctrl-K.]