Is it possible to use CCTray 1.2 to access older Cruise Control .Net 1.0? I was thinking it should be possible to use the "Supply custom HTTP URL" option, but I don't know how to configure it.
I would think it is possible as 1.3 and 1.4 intermingled quite nice. I think the URL form you are looking for is http://yourwebhost/ccnet at least that is what works in 1.3 and 1.4 I will point out 1.4.3 should be out soon, and with all of the bug fixes and added functionality 1.4.3 would be a good upgrade target if you are thinking of going that way, then you could get everything back on the same version.
Related
We have SAP Hybris Commerce version 5.1.1 with custom extensions installed. Now we need to upgrade it to newest version 6.2.
My question is: Can we upgrade it to 6.2 and skip all versions between 5.1 and 6.2? Or must it be done by upgrading to 5.2, then to 5.3 and so on?
Yep - 5.1.1 to 6.2 ought to work (I've been working on a project that's done exactly this).
You will probably have to make some changes - watch out for any customisations you've made - it might be worth reading through the release docs to have an idea of what's changed - off the top of my head the structure of add ons is one area that's a bit different between 5.1 and 6.2, but otherwise things should work OK in theory.
Yes you can directly update to 6.2.
It's important to regulary update your hybris version. You should not have so much gap with current version. Indeed it become tougher to migrate your custom code.
Upgrading each minor version in a row is totally useless most of the time. Only do this if you have issues you can't solve while migrating to the target version.
You should take a look at this migration documentation and this guide (it can be used even if it doesn't match your version).
Note that some stuff like promotion are totally different in hybris 6 so you can expect some trouble to migrate everything. Take care of your extensions generated with old template also.
5.5.1 introduces JDK8 and Spring 4, I would not underestimate this change! Depending on the size of your project I would first go for 5.5.1. Also notice the MySQL change for 6.2 (5.6). Don't forget to declare deployment tables in your items.xml. Search for "third-party compatibility" and "release notes" on the wiki. Also try shifting to the backoffice since the hMC is marked as deprecated.
Yes you can migrate directly 6.2.
The time and difficulty depends on your custom code (and how much it respects good practices : naming conventions, usage of service, architecture respect...etc)
You might also consider that HMC is deprecated in 6.2
I'm migrating from a HD to an SSD. I was using TortoiseSVN 1.7 on the HD for a project that has multiple coders using the same repository.
I installed TSVN 1.8 on the SSD, and am attempting to use it with the project's old-format working copy. It asks me to upgrade the format to 1.8, but I'm wondering if that permanent change is going to make its way back into the repository when I do my next checkin, and if that is going to cause problems for other coders not using the new format.
Thank you.
No. Internal local changes of WC structure doesn't reflected in remote repository: there are only a few compatibility issues between server- and client-side versions of SVN
LazyBadger is correct but a few more details are worth noting:
Be aware of the distinction of the SVN server vs the SVN client; TSVN is a client, existing separately on the machine of each developer. Thus, this question is addressing upgrading a client specifically.
When it asks you to upgrade the format to 1.8, it is talking about the infrastructure of your working copy, the way it stores and manages files on your box. That infrastructure is local to your machine; it is not reflected on the server.
However, it is not a general rule that you can always upgrade a client and remain compatible, but moving from TSVN 1.7 to TSVN 1.8 does, in fact, maintain compatibility.
Ultimately to answer this question each time you are considering an upgrade, have a look at the TortoiseSVN release notes--for 1.8 they are here. In there you will see that it specifically states that "Older clients and servers interoperate transparently with 1.8 servers and clients."
I am a beginner in Azure and have come across a task to change the storage version.I basically found that the versions are obsolete and need to upgrade them as per http://blogs.msdn.com/b/windowsazurestorage/archive/2014/08/05/microsoft-azure-storage-service-version-removal.aspx
So, in one of the paragraphs its mentioned
"What to change
If you find any log entries which show that version to be removed is being used, you will need to find that component and either validate that it will continue to work (unversioned requests may continue to work as their implicit version will simply increase – see above), or take appropriate steps to change the version being used. Most commonly, one of the following two steps will be used:
1) Change the version specified in the request, typically by migrating to a later version of the libraries/tools. When possible, migrate to the latest version to get the most improvements and fixes.
2) Set the default service version to one of the supported versions now so that the behavior can be verified prior to removal. This only applies to anonymous requests with no explicit version. "
Question is, how to go about implementing point 1 and 2 ?
Thanks
Since your code is written in C# and uses Azure SDK your best bet is to upgrade it to a "new enough" SDK. It's unclear whether version 2.0 or 2.1 is the lowest required. So your route is the following:
First, check if you really have to do anything.
You check which Azure SDK your service uses. If it's 2.1 or higher you don't need to worry yet. If your're unsure - use Fiddler to validate the version headers as explained in the linked to post.
If you use Azure SDK 2.0 you'd better check the version headers as explained in the linked to post.
If you use Azure SDK prior to 2.0 you are surely affected and have to upgrade.
So if you found you do need to upgrade you'll have to download and install the newer SDK and then remove references to old SDK assemblies from your projects and add references to new SDK assemblies. Then you try to build your code and maybe fix a lot of calls because SDK interfaces have changed (that's what I see migrating from 1.8 to 2.4). Once it builds you test it works fine and then you remove the old SDK version to ensure the code builds without it present.
There was a breaking change between 2.1 and 2.2 - the latter only support Visual Studio 2012 and higher. There was another set of changes in Azure Diagnostics functioning between 2.4 and 2.5 which are so long to read that I chose to migrate to 2.4 instead of 2.5.
According to groovy-eclipse plug-in website, groovy-eclipse plug-in supports certain groovy versions, 1.8, 2.0 and 2.1. This seemed a bit restrictive to me. What am I supposed to do if I work with groovy 1.9 or 1.7?
Perhaps the answer is that if you worked with Eclipse or GGTS before, then that couldn't happen; I suspect they never supported 1.9 or 1.7.
What is your concern? If you're worried that you might start off with 2.1 and have it not supported in future, then don't worry. If you're expecting to use some bizarre compiler feature that only worked in 1.9, then edit with the eclipse plugin for any version, and run Groovy (or Grails) from the command line with the right configuration.
Hope this helps...
Charles
Groovy-Eclipse supports the last couple of versions of groovy so we don't get into a maintenance headache. There is no Groovy 1.9 so we support right now 2.2/2.1/2.0/1.8 - we dropped 1.7. If you want to use 1.7 you would use an older version of groovy-eclipse that supported it. See version 2.8.0: http://groovy.codehaus.org/Groovy-Eclipse+2.8.0+New+and+Noteworthy - on that page you can download an update site archive that will give you groovy-eclipse and groovy 1.7.10
The latest stable release of Mono right now is 2.4.2.3. Does subsonic 3 work with it? I know Mono isn't compatible with all .net 3.5 features yet, but I'm presuming compatibility depends on which specific language features of .net 3.5 Subsonic uses. Does anyone know for a fact whether it's compatible?
Its compatible - just remember to use an actual version of MySQL connector, if planning to use MySQL.
And there is an Error in current SubSonic (see Issue 111). Change IsDbNull to IsDBNull in SubSonic.Core/Linq/Structure/ExecutionBuilder.cs and recompile.
That did it for me with Mono 2.6 and MySQL-connector 6.2.2
But I didnt't test anything but simple save and read queries.
from the looks of the code not everything seems to be full hilt 3.5 so i would cast an opinion that it will be just fine, i have been using 3.0.0.3 and resharper comes up with tones of comments about how it can be changed and upgraded.
but it takes less than 5 mins or so to test, so i would go ahead if i was you, you dont really have much to loose other than 5-10 mins.
hope this helps