|
I review the changes and fixes and check if there is anything I use (not automatically using a library means you use all of it)...
If there are relevant changes I test and update, otherwise I do nothing...
I have libraries that are 10 years old and never had a reason to update them...
"The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge". Stephen Hawking, 1942- 2018
|
|
|
|
|
If I'm dealing with a known issue and the update is supposed to fix it, then I update immediately. Otherwise I'll wait and watch whatever chatter there is about the new version. There are a few, like ScintillaNet[^], where I don't hesitate. I'll grab it as soon as it's available.
Sometimes the true reward for completing a task is not the money, but instead the satisfaction of a job well done. But it's usually the money.
|
|
|
|
|
If at all possible, I do not change the toolchain, external libraries, or any other component not under my control in the middle of a project. This is not asking, but begging for problems.
When performing major upgrades to an existing project (adding major new functionality, porting to a new processor, etc.) I have updated the toolchain and/or external libraries before starting work, if they provided extra functionality or bug fixes. This is justified because the project will in any case undergo full tests before release, as if we were starting from scratch.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Same here.
|
|
|
|
|
Wait a few weeks/months for other people to test the new version for me and find all the bugs in it.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
There's always one more bug...
|
|
|
|
|
or two, or three...
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
I let other developers (and by proxy, their users) give it a good testing for me, let the bugs be worked out, the "rev" updated a few times. Early adopters are, more often than not, on a fools errand.
Then - if it's free - maybe we're talking business.
Ravings en masse^ |
---|
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
My group is still on VS2013. As I have stated earlier I never really felt that VS2012 or VS2013 were worth bothering with. Now I really like VS2015, but that really is because of improvements in C#. Needless to say my organization is far from up to date, and that is Visual Studio, why bother with third party improvement when you are 5 years out of date of the basic development environment.
|
|
|
|
|
My most recent build was with VS2008. I needed to modify an application and that was the home of the source code. It worked beautifully in that realm and there would be no advantage to changing anything. I've installed newer version - but have had little to no use for them.
(Not to be taken as a contest - just pragmatism!)
Ravings en masse^ |
---|
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
W∴ Balboos wrote: (Not to be taken as a contest - just pragmatism!)
I still have a DOS VM with MSC 6.0ax installed. I haven't done much with it recently, but it's there if I ever need it.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
|
Still on VS6
GCS d-- s-/++ a- C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
I know a few years ago there were a lot of people still on VB6. Microsoft did not do a good job in migrating to VB.Net as is shown by the number of people that stated with VB6. VB.Net was a fairly significant hurtle for the VB6 people to jump unless they had to.
|
|
|
|
|
I change because change is good and new is good so updating is goodier than good, right?
I save a copy of the version of the libraries I use in the source folder. 20 years from now on the same system everything will work (or not work) exactly as now.
GCS d-- s-/++ a- C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
with some open source xmpp library (don't want to do name calling here)...they did so many compatibility breaking changes, version for version, then the updates are not on maven, for MONTHS... we lost many weeks to get such a version change done, it was close to break our production out in the field! Never...never...NEVER again!
Horrible.
We stick to working versions as long as possible. In general, the experience we had with that xmpp library drove us far away to use such libraries again in the future. that's simply nothing where a production scenario can survive.
Mostly it's reduced to cherry picking of some ideas or solutions from open source libraries/frameworks, but in general we create what we need in-house now.
Reduce external dependencies as far as possible, especially when it comes to open source. What we had with this library destroyed our faith in open source hard.
Sure, there are some really amazing and big frameworks/libraries out there and it's hard to bypass them when you are working towards a specific functionality, but for the future we'd rather invest 2 months in development in-house than to risk that something like that happens again.
|
|
|
|
|
Why didnt you test it before or applied some rollback strategy.
For me as seasoned M$-developer an update is always a risk of blowing all up
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
It was not a matter of testing - it was pure need of that functionality as our server (which is developed by a third party) changed the implementation to the new extensions and we were in need to upgrade.
I don't say, that this all was not (partially) our fault, we didn't examine good enough what that upgrade would mean (in good believe of "what shall happen, if we upgrade?") and we gave our GO to the server upgrade.
What followed was chaos.
|
|
|
|
|
I only update major versions (can't be bothered with the minor ones) and let my users test in production.
I don't pay them so they're like free employees
|
|
|
|
|
Ah! Mr Gates, sir! I didn't know you had an account!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
What is the intended difference between these two options? They seem the same to me.
* Upgrade only if there's no option (need the new functionality or fixes, or old version no longer works)
* Steer clear if at all possible. If what we have works we aren't going to break it.
modified 13-Sep-18 21:01pm.
|
|
|
|
|
First one means you do it yourself.
Second one means you find an unassuming poor sod in your team and ask him to do the upgrade. Then you stand somewhere in the corner where you can see his reactions when he tries to avoid screaming swear words in office.
"It is easy to decipher extraterrestrial signals after deciphering Javascript and VB6 themselves.", ISanti[ ^]
|
|
|
|