Hi Robert, Stefan,
On Tue, Mar 26, 2019 at 3:37 PM Robert J. Clay <rjclay(a)gmail.com> wrote:
> There's not that much of a dojo related
version difference with what
> LedgerSMB 1.6 uses (Debian testing has v1.14.2) but that's not the
> case for LSMB 1.7 so it's something I need to look at in any case.
Actually, as I read that sentence, you're saying that LedgerSMB 1.7 doesn't
use Dojo 1.14.2 (and depending on how you read it, that LedgerSMB 1.6
does). However, that's incorrect: It's LedgerSMB 1.7 (which isn't currently
in Debian Testing/Buster) uses 1.14.2, but LedgerSMB 1.6 - which *is* in
Testing - uses Dojo 1.13.
To be honest, I see that Dojo 1.15.0 has been released and I'll likely at
least switch master over to that. (I think it's too close to the 1.7
release to change the Dojo library version right now.)
Actually I don't think that is a good idea. The
release cycle starts
again after buster is ready, and there is enough
time to get dojo in
sync with what is in LedgerSMB.
Well, the problem is that in the past I've seen different versions of 1.x
Dojo requiring adjustments in our code base to support Dojo version
upgrades or downgrades. As a result, we advise to run LedgerSMB against the
Dojo version it comes with, or optionally any other patch-level version,
but *not* any other minor-level version, not even when that version is
higher than the minimum required.
Or at least, with the dojo toolkit itself. A reason
includes it is because that version can get of sync, pariticularly
with released LSMB versions, which track the major/minor version of
dojo from at the time that the LSMB version was released.but might get
the patch level version number sync'ed occasionally. (This is done
using sub-modules in the LSMB code repository against the dojo code
Yes. Patch-level version differences are ok, although I've seen patch-level
releases break functionality LedgerSMB depends on (unintentionally, with
follow-up patch level releases fixing it again).
All in all, the Dojo release being used seems somewhat fragile and needs
thorough testing before the combination is geing changed.
Also it is the general policy in Debian to
use the available packaged version instead of
including it in the
application package. This is for various good reasons (maintenance,
package size, ...).
Yes, I know; it's why I changed the 'ledgersmb' pkg to use the
Debian dojo pkgs when LSMB started using dojo 3 years ago. I also know
that the policy  is a 'should' not a 'must'. OTOH; I don't yet
how much, if any, the version difference might actually make.
Especially over a patch level difference like that between 1.14.2 &
1.14.3. Which likely means that I should really focus first on
gettting the 'ledgersmb' pkg working with autopkgtest.
The difference in lines of code between 1.14.0 and 1.14.1 was pretty small,
but it did mean broken file-uploads in LedgerSMB on Safari. Yes, getting
the package build working with automated testing seems like a great way to
do the required quality assurance needed to make sure another Dojo version
can be used with LedgerSMB than the one that comes with the tar archive.
-- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.