HI, In mongodb site there are two setups available in production release.So what is nightly whats the difference between 1.6.5 and nightly?
I would expect the 1.6.5 one is the official build release for that version. The nightly build is most likely the nightly build for that branch of development.
If there was a bug (security issue, whatever) which was discovered in 1.6.5, it would likely be fixed (over however many days it might take), at which point the fix (which may or may not be feature-complete) would appear in the nightlies, but not yet in the final release above it. When they were happy it was ready for release, there would be a new release from the 1.6 branch (most likely 1.6.6) and the cycle would continue until the 1.8 branch (which is currently 1.7) replaced 1.6 as the stable GA branch. MongoDB's version numbering strategy is explained here.
I hope that makes sense, and I believe that would most likely be what happens. Of course, if anyone is involved in MongoDB's development and wishes to correct me, feel free. :)
Related
I'm currently using EF7 - beta4 and would like to use beta6. I know I'm playing with fire by using nightlies, but has anyone else done this and have been able to build after upgrading?
I've added the nightly nuget repository: https://www.myget.org/F/aspnetvnext/api/v2/ but when ever I upgrade a package it totally trashes all of .net in both DNX 4.5.1 and DNX Core 5. Now I'm not crazy enough to do this in a working project, so I'm testing this out in new empty mvc project and when I attempt to build I get in excess of 2000 errors from everything.
Has anyone else attempted this and if so how does one get around all the errors?
The nightly builds are highly unstable. Here are some pointers for working on the bleeding edge of ASP.NET.
Reset all packages. Sometimes nightly builds break other packages. Delete project.lock.json and delete all packages (~/.dnx/packages/). Reinstalling may help you get a coherent set.
Upgrade DNX. dnvm upgrade -u. This installs the latest, unstable version of DNX.
Submit issues. If it's breaking for you, it may not just be you.
Pay attention to the ASP.NET on GitHub. Nightly builds are usually only a few days behind the latest changes to the dev branch. We are working fast, and breaking things.
If stability is important, stick to the Nuget.org betas. Beta5 was just released yesterday, and has been more thoroughly vetted for stability.
Watch the Announcements repository to receive a heads-up on breaking changes.
I understand that NuGet packages update process is not automatic for a good reason (a new version could break your code or cause unforeseen problems), but then it transfers the responsibility of updating all packages to the developers themselves. When exactly should we be updating NuGet packages for a given project? Are there some guidelines regarding this process?
In our current project, this is more or less arbitrary: I update packages whenever I remember to check for updates, and preferably at the start of a sprint so that, if there are problems with the newer versions, we are able to fix them or rollback to the previous versions of the offending package. Most of the time, I'm the only developer that worries about this stuff, but I feel it is valuable to always be as up to date as possible because of performance reasons and new features that can make our work easier.
Well, you should update whenever you are able to cope with it.
So you need to think carefully about the regression updating the packages could cause to your application if already in production, or the extra tests you are going to need to carry on in order to verify everything seems to be working as expected.
Normally updating to newer minor versions shouldn't cause much problems, but you always have the risk of it. Looking at the newer version release notes could prepare you to what to expect of the update.
In summary, update when you can cope with it, and you are ok with any shouting from your testers if suddenly the system regress without them even knowing it was coming :)
Few tips to decide package update strategy:
Don't run production application on a deprecated (not-maintained) package version. Upgrade to a maintained version at bare minimum if unable to upgrade to latest.
Don't run production application on a pre-release (not-stable) package version. Upgrade to a stable maintained version.
While upgrading by a major version, read publisher's release notes to understand the implication backward-compatibility from application context. This will help put a better estimate on development and testing efforts.
I use Github for managing my code.
Is it bad style if I would delete a release which has a big and clear error and people will have trouble with it?
The thing here is that on my machine I had no troubles, but if you are on MAC the plugin will bomb the application.
What do you do in these cases?
Just release a new version increasing the patch level, this is called semantic versioning.
If your version number is 1.0.0, release a new one with number 1.0.1, and explain which bugs were fixed in your changelog file.
I am upgrading my server from an old version of Mercurial, 1.5 to the newest version. I am wondering if the 2.2 build of Mercurial is stable for use by multiple users at a time. Also are there any gotchas when upgrading like my custom hooks not working, or a buildslave object not working? I have not done a major upgrade on a source control server before so help would be appreciated.
Mercurial is famouse for being very strict regarding compatibility. Have you checked upgrade notes? It list all breaking changes between version. Biggest change for me is introduction of hgweb in 1.6.
Biggest exception from compatibility rules are hooks. Mercurial doesn't guarantee anything so only way is to try.
Also consider making update in two stages. For example first to 1.9 and than to 2.2.
I'm currently testing Memcached in a Windows machine and we are planning to use it in production while Microsoft Velocity is still in CTP. It is running well so I believe that Memcached for Windows will do well when our site is already in production. I'm reading some blogs pertaining to this issue and some of them just mentioned that it must not yet be used in production.
If there are issues, please tell why? And please, if you have any links about this matter, just post it here. Thanks.
There is no official release of memcached on Windows. We're working on it right now, but unless you're pulling from a dev branch or you've downloaded a pre-release, you've definitely got an unsupported version with a large number of bugs and missing features from the last couple of years.
I've been using memcached in production for several years now (since early 2008). We're currently using a 12-instance cluster and it absolutely hums. I would recommend memcached any day of the week.