On Tue, Mar 26, 2019 at 3:37 PM Robert J. Clay <..hidden..
> > 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 why LSMB
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, security,
> 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 know
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.