Hi Chuck, 1) We have not scheduled any further bug fixes for 11.1. If something critical comes up that doesn't have a work-around and there are solid reasons people cannot move to 11.2.x to receive the bug-fix, we would investigate a further 11.1.x bug fix release. As a general rule we try to make sure we strike the right balance of focusing on moving the technology forward and making sure we meet business realities.
As building & QA'ing products is expensive in time, even for bug-fixes, the longer we back-port fixes to a not latest version it reduces the number of both new features and bug-fixes for those that stay on the current major versions. As before, if you encounter a bug in 11.1.15, it will depend on several factors and the response we be based upon knowing them. For instance, I'm fairly confident that fixing something non-critical like a misspelled log message wouldn't be back-ported whereas a critical security bug probably would. 2) Why the potential jump to 12.1? Well, you'll just have to see, but it would seem it should be something big, right? :). I say potential as I'm a big fan of "Nothing is real in software until it's been shipped." 10.3 to 11.1 predates my involvement, but the reason was a major change throughout the product. It was an underlying change that affected essentially the entire product. This was needed to implement an enhanced version of UniData's replication system to replaced UniVerse's original one which had several short-comings that were not salvageable. While U2 MDM did have some changes to UniVerse, they really were minor and didn't involve affecting existing functionality. From that point of view it was some trivial tweaks to support an external tool. We now try to follow x.y.z versioning, where 'x' indicates huge architectural changes either to the product internally or for users of the software. 'y' indicates major features and major bugfixes, 'z' indicates minor bug-fixes and the occasional minor enhancement. We do try to minimize enhancements at this level, although occasionally it is commercially unavoidable. As to your comment on "due to past wounds", this is something we have talked extensively about as a team last year and re-iterated at our kick-off meeting for 2014. Enabling customers to be confident that they came upgrade from current-1 to current is of paramount importance to us. If you run into anything new we introduce that breaks that goal, after you've raised via the normal channel, send me a email personally with the issue reference number. Regards, Dan -----Original Message----- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Charles Stevenson Sent: Sunday, March 02, 2014 2:14 AM To: U2 Users List Subject: Re: [U2] Recommended 11.1.point release to upgrade to. Dan, Thank-you for responding. More generally, thank-you for monitoring u2-list so closely. So, under the theory that no good deed should go unpunished, I have a couple follow-up questions for you. 1. Your "*planning*" comment confuses me. It can be taken 2 ways. Are you saying Rocket is (a) planning NOT to do 11.1.x bug fix releases; or (b) not CURRENTLY planning any such bug fix releases because none have been identified yet? For example, John Hester's localtime() / telnet problem surfaced in 11.1 (telnet handling changed dramatically at 11.1 to accommodate the Date Replication changes), I would think you would offer an 11.1.x bug fix so a user does not need to do a major jump to 11.2 to get the fix. I suppose it depends on whether there is a good workaround, & Mr. Hester seems satisfied with his. Because 11.1 is still in "GA" status, and because 11.2 is still young, I would think bugs that are found to be in 11.1 would still be fixed with an 11.1.16, .17, etc.. At this late stage of 11.1 I would think the only releases would be unplanned bug fixes. Yes, unplanned until another 11.1 bug is found, but once found, let the planning commence. If you've followed this thread, you'll recall my organization is extraordinarily reluctant to make install major uv releases w/o extensive regression testing due to past wounds. If we encounter a bug in 11.1.15 will we be told, sorry, no fix unless you upgrade to 11.2.x? That won't sit well. It even negates my reason for going to the highest 11.1.x instead of a point release with a plethora of current satisfied users. 2. The version numbering scheme itself confuses me. What sort of thing would call for a jump from 11.x to 12.1? (Or will it be 12.0?) vs. 11.n to 11.[n+1] ? Why was it called 11.1 instead of 10.4? The new Metadata Manager (U2 MDM) was introduced in 11.1.11, a minor point release. To my way of thinking, that would have triggered "11.2". And the existing new 11.2 would have been called 12.1. I thought the minor point releases were generally for bug fixess, not new functionality. Maybe you could clarify the naming scheme? Thanks in advance, Chuck On 2/28/2014 8:25 PM, Daniel McGrath wrote: > Hi Charles, > > It does not affect Windows. At this point, we are not *planning* any further > 11.1.x releases so we can focus on the 11.2.x and .NEXT releases of UniVerse > and moving the technology forward. > > I also misspoke on 11.2.4 as it was a mistake in our issue system. It is > actually 11.2.3. > > Regards, > > Dan > > -----Original Message----- > From: Charles Stevenson > Sent: Friday, February 28, 2014 9:31 AM > > is this unix-, linux-specific > or windows, too? > Fix in 11.2.4, but in 11.1.16 too? That's the usual practice, isn't it? > > On 2/28/2014 6:50 PM, Daniel McGrath wrote: >> As an FYI, I'm sitting in a meeting now were we are pulling a check-in to >> use a re-entrant version of the function for our latest build to fix this >> issue. You should expect a fix in 11.2.4 unless something goes wrong. >> >> Regards, >> Dan >> >> -----Original Message----- >> From: John Hester >> Sent: Thursday, February 27, 2014 4:59 PM >> >> We migrated from UV >> 10.2.7 on RedHat 5.1 x86 to 11.1.13 on RedHat 6.4 x64 last November. I've since run into a bug that can reveal itself when tty processes are terminated. It could be unique to linux, but you may want to watch for it. The symptoms are that terminated UV tty processes disappear from LISTU and PORT.STATUS, but continue to exist in the process table and consume a UV per-seat license. I discovered the issue when we ran out of licenses after a couple of months of uptime and I initially couldn't figure out where they went. Running the "ps" command at the OS level revealed their existence. I'm guessing the issue occurs on maybe 1 out of 200 or 300 tty sessions. >> >> The root cause of the issue is the localtime() function being called from >> the signal handler. The localtime() function is not POSIX >> async-signal-safe, which means it can't be safely called from there. The function acquires a lock which may already be held by the process that was interrupted by the signal if it too was in localtime(). When this happens, a deadlock is the result and the process is in limbo forever. I was able to easily work around the issue by having cron run a script after hours every day to clean up any hung UV processes and recover the licenses. I opened a ticket with Rocket, and they're planning to include a fix for the issue in 11.2.4. >> >> I'm happy to provide my workaround script to anyone who runs into this on a >> linux or unix box. Unfortunately, I'm not sure how one would craft a >> workaround on Windows. >> >> -John _______________________________________________ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users _______________________________________________ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
