A question occurred to me; is it fair to assume for example, that the fixes that came out in 4.1 SR-4 today, will be in the next release of 4.2 beta?
I hope so..
Yes, that's what they've assured us in the past. I can't point to a specific thread.
As a former developer, it boggles my mind to think of how they keep track of merging all these changes into two different forks of the source code. It seems to me that it would be a process very prone to human error. It's mystifying how they can be working on the new features for the next release while still releasing betas in the last release cycle, too, without risking overlooking some changes or having to painstakingly manually merge changes that were made in the same lines of code. I just hope they've got some good process in place to make sure they don't miss anything.
I just hope they've got some good process in place to make sure they don't miss anything.
We'll find out[;)]
As a former developer, it boggles my mind to think of how they keep track of merging all these changes into two different forks of the source code
Rosie, most of the higher level source control products do most of the work for you. They automatically integrate in if the source file is identical, it presents suggestions for acceptance, tracks changes, allows undos and rollbacks, etc. It's not simple, but software makes this much easier with good procedures.
As a former developer, it boggles my mind to think of how they keep track of merging all these changes into two different forks of the source code Rosie, most of the higher level source control products do most of the work for you. They automatically integrate in if the source file is identical, it presents suggestions for acceptance, tracks changes, allows undos and rollbacks, etc.
Rosie, most of the higher level source control products do most of the work for you. They automatically integrate in if the source file is identical, it presents suggestions for acceptance, tracks changes, allows undos and rollbacks, etc.
Ah, it figures. I haven't used source control for about 14 years, and back then it was the in-house developed SLM (Source Library Manager) which we affectionately called "Slime." I'm sure source control software has come a long way since then. SLM did keep track of the history of changes, and it would offer to automatically merge for you if two people had a file checked out at the same time and both made changes and checked it in. But you'd have to manually fix it if both people made changes in the same lines of code. And it couldn't handle multiple source forks.
It's not simple, but software makes this much easier with good procedures.
Yes, "good procedures" is the key. From what I've seen in the past with release glitches and missing metadata and such, I don't have as much confidence in Logos's procedures as I wish I did. I think they're improving. So far I haven't seen anything that was introduced in a previous release and then went missing in a later release. But there have been mysterious bug regressions, so that could be the cause of them...
The relationship is more complex eg. if the fix was already in the Beta! A problem detected in an SR may only be released in a beta; if urgent then it will be released in an SR. If you know that the problems in an SR also affect the current beta then it may be safe to assume that a fix will be in the next beta.
Available Now
Build your biblical library with a new trusted commentary or resource every month. Yours to keep forever.
