-
Notifications
You must be signed in to change notification settings - Fork 133
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reader programming feature #52
base: master
Are you sure you want to change the base?
Conversation
Except of the comment in review, PR looks legit and can be merged, if it doesn't break anything and keeps old behaviour for "old" clients |
changed to DmtxBoolean, waiting for the next release 😃 |
@msva tested today with other barcode generator, reader programming is ok. |
well, but tests (and so default build configuration (where tests are enabled to build)) fails (as there is a change in parameters count in encode function. Same failure would happen for every program, that links to libdmtx and uses So, this means that we need either:
I personally would prefer the sesond variant (not sure in which sub-variant), but it would require more work than just "fix tests", tho 🤷 |
I run test just now, didn't see them before. so you would be able to build a version that has new or old signature depending on some configuration flag, right ? |
As one of the possible solutions - yes. Assumes, it will define some parameter, that will trigger
Actually, it would be better, to add it to both, as CMake is considered as primary buildsystem, but you can add it to autotools, if you prefer, and I'll port it to CMake too a after merge. |
Another variant is to go further, and make C11 (or newer) as minimum C standard to build the library. |
Yes, this is the idea: a configure optional flag to undef the breaking feature of reader programming.
I do not know CMake and I'm building the library without it, so I cannot help on this task. |
with latest two commits, it's possible to build the library in following ways:
with both the configuration, |
Should a breaking feature be enabled by default? |
Depends on which version will be released, if project follows semantic versioning:
- On a v1.0 , yes (major version increment can add breaking changes)
- On a v0.8 surely not (it’s only a minor increment without breaking changes)
The point is that, even if it will be called v0.8, if the feature is enabled it will break the backward compatibility, so it’s a non-sense call it v0.8 .
Anyway, for now it's enabled by default until a decision from repo owner will be taken on this point, and I’ll eventually do change next days.
… Il giorno 16 dic 2022, alle ore 18:44, Jon Trulson ***@***.***> ha scritto:
Should a breaking feature be enabled by default?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.
|
Hi @msva , I've just added a gihub workflow to build and test the project, could you enable actions through project's Settings ? Then, I would know your point about reader programming feature's default: is it ok for you to have it default enabled ? Thanks, |
it's all about spaces and alignment
I've just added a commit which "beautifies" the code, it's all a matter of whitespaces.
I agree to have a new major release number, @msva I'm waiting for it and I'm hoping it will be done very soon, thanks. |
hi @msva , with recent changes I've:
I hope you've some time to review this PR, thanks! |
hi @msva , any news about reviewing this PR ? let me know if style changes clutter too much the review and if you prefer a different PR for that changes. Regards, |
Hi! Sorry for disappearing (I had some issues). Talking about this PR: as I see, some critical notes I posted above still actual. First of all, that programming feature is still enabled-by-default, as I see, while it should be disabled by default, at least for few near versions (at least until major version change) to not break compatibility with applications. Next, did you performed test with applications, that uses libdmtx, that they don't crash and keep working with modified version, if they know nothing about reader programming, and was linked against non-modified version? And that they compiles with modified version and works fine afterwards? As I see, merging the code as is will brake many, if not all, applications that use libdtmx 🤷 |
Hi !
quoting myself:
I've no idea of which will be next release number or any plan of this project.
I tested it into this package, it works as expected:
The feature adds a breaking changes for libsdmtx users, so enabling it means at least to change their code. |
Well, my point is that there is no plans to release 1.x at the moment (or it will require to temporal split to separate branches, and keep supporting old branch and release patch-releases for some time. So, it is necessary to either you rewrite code a bit to make it disabled by default, or me doing thar after merging (but unfortunately, at the moment I've no enouth spare time even on holidays, so I'd be able to do that myself not earlier than winter. So, if it is okay to wait few months, I'll merge current state and will fix default state myself. If you'd like to merge it right now - can you, please, rewrite that part. Btw, future note: it would be nice to perform style and indentation changes/fixes in separate PRs (from code changes), as they're making reviewing harder. |
Well, actually, I have "time issues" even furing winter. |
Hi. Sorry for delays. It was so much things happened since I tried to review that, so I was unable to proceed. Can you, please:
I'll try to review and merge it ASAP after that Thanks in advance! |
Thanks for this useful library.
This PR is to add Datamatrix label programming feature through a flag, passed from outer methods to the one that really uses it.
@msva please review, thanks 😃