23 Mar
2019
23 Mar
'19
6:45 p.m.
Note that due to illness; although I updated our 'ledgersmb-1.6' pkg
for v1.6.10 I haven't yet updated the 'ledgersmb' pkg for that version
so what's in Debian Testing is still only v1.6.9. And since the hard
freeze in preparation for the Debian release of Buster as the new
stable has gone active, there is no more auto migration to Testing for
updated packages in Debian unstable until after the new version has
been released.
Besides still waiting for the last 3 debconf translations so that the
pkg can be updated with them, I've also been thinking about a major
change in the package; that being changing it so that it uses the dojo
distributed in the LedgerSMB archive instead of that in Debian like is
already being done with our 'ledgersmb-1.6' package, on the basis that
the version in Debian is not the same as that actually being used by
the app itself.
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.
A ledgersmb package with major changes could always be uploaded to
Debian Experimental (& our package repos, of course), so that's what
I'll be looking at doing if necessary.
Related to that is still getting the autopkgtest functionality done
for the package. That (which does 'as installed' testing) is useful I
think in any case but in particular having to do related to the
different dojo versions. But that is based on my thinking that the JS
code is actually being at least somewhat exercised in the 't/' and or
'xt/' testing, which I was wondering about due to something one the
other devs said/ but which I've been assured that the JS code is being
exercised in the bdd tests in xt/. So I figure to work on getting the
t/ tests working for the autopkgtest to start off with and continue
from there to the xt/ tests.
Any comments/questions/etc, please let know.
--
Robert J. Clay
jame(a)rocasa.us
rjclay(a)gmail.com
25 Mar
25 Mar
9:27 a.m.
On 3/23/19 7:45 PM, Robert J. Clay wrote:
Note that due to illness; although I updated our
'ledgersmb-1.6' pkg
for v1.6.10 I haven't yet updated the 'ledgersmb' pkg for that version
so what's in Debian Testing is still only v1.6.9. And since the hard
freeze in preparation for the Debian release of Buster as the new
stable has gone active, there is no more auto migration to Testing for
updated packages in Debian unstable until after the new version has
been released.
Besides still waiting for the last 3 debconf translations so that the
pkg can be updated with them, I've also been thinking about a major
change in the package; that being changing it so that it uses the dojo
distributed in the LedgerSMB archive instead of that in Debian like is
already being done with our 'ledgersmb-1.6' package, on the basis that
the version in Debian is not the same as that actually being used by
the app itself.
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 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. 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, ...).
Regards
Racke
A ledgersmb package with major changes could always be
uploaded to
Debian Experimental (& our package repos, of course), so that's what
I'll be looking at doing if necessary.
Related to that is still getting the autopkgtest functionality done
for the package. That (which does 'as installed' testing) is useful I
think in any case but in particular having to do related to the
different dojo versions. But that is based on my thinking that the JS
code is actually being at least somewhat exercised in the 't/' and or
'xt/' testing, which I was wondering about due to something one the
other devs said/ but which I've been assured that the JS code is being
exercised in the bdd tests in xt/. So I figure to work on getting the
t/ tests working for the autopkgtest to start off with and continue
from there to the xt/ tests.
Any comments/questions/etc, please let know.
--
Ecommerce and Linux consulting + Perl and web application programming.
Debian and Sympa administration. Provisioning with Ansible.
26 Mar
26 Mar
2:37 p.m.
On Mon, Mar 25, 2019 at 5:27 AM Stefan Hornburg (Racke)
<racke(a)linuxia.de> wrote:
On 3/23/19 7:45 PM, Robert J. Clay wrote:
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
repository.)
.... I've also been thinking about a major
change in the package; that being changing it so that it uses the dojo
distributed in the LedgerSMB archive instead of that in Debian like is
already being done with our 'ledgersmb-1.6' package, on the basis that
the version in Debian is not the same as that actually being used by
the app itself.
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 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. 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 [1] 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.
--
Robert J. Clay
rjclay(a)gmail.com
jame(a)rocasa.us
[1] https://www.debian.org/doc/debian-policy/ch-source.html#convenience-copies-…
6 Apr
6 Apr
2:26 p.m.
Hi Robert, Stefan,
On Tue, Mar 26, 2019 at 3:37 PM Robert J. Clay <rjclay(a)gmail.com> wrote:
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.)
> 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 I don't think that is a good idea. The
release cycle starts
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.
again after buster is ready, and there is enough
time to get dojo in
sync with what is in LedgerSMB.
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
repository.)
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
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.
--
Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
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 [1] 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.
1453
days inactive
1467
days old
3 comments
3 participants
participants (3)
-
Erik Huelsmann -
Robert J. Clay -
Stefan Hornburg (Racke)