Using with go-1.11 and dependency go.mod system
vit1251 opened this issue · 5 comments
Hello, could I ask you create version tag like v1.0 to start using with go.mod system. Thanks.
I'm not sure how much llgcode knows about this new feature but I'm only hearing of it now. It definitely looks useful, but we haven't really been versioning yet (AFAIK). But this looks like something we should follow in the future, when we start versioning the code and making API changes in new versions. This could really help us refactor sections of code while still being able to point users to the old API with ease while they migrate (or whatever happens).
agree with you @redstarcoder, how could we versioned draw2d?
@llgcode it would be great, if draw2d is versioned. The documentation is here - Publishing a release. However, please read sections before How to Prepare for a Release.
Release of version v1.0 would provide confidence, that this library should have stable enough API to be included in non-hobby projects. Assuming, the draw2d project would adhere to semantic versioning, and breaking changes increment the major version.
If you're not yet confided enough about API stability, there are various options how to indicate user, that a function/interface/struct is considered experimental, and might be changed in future.
Hi @kravemir ,
I do not work much on this project, I advise you to turn to these projects which are better maintained:
https://github.com/tdewolff/canvas
https://github.com/fogleman/gg
I can give you some support if needed on some small fixes, some bug fixes here and there will however be possible. I could publish a release if that helps you, but I cannot promise you big changes in this project, I will read your links.
regards
@llgcode thank you for the answer. I'm currently using github.com/jung-kurt/gofpdf, and was evaluating this library and then also ones you've recommended.
Looking at github.com/tdewolff/canvas it seems to be powerful, but quite immature beast. The root package is depending on 3rd party chart and plot packages, which should be definitely optional, as many library consumers documents don't need that, and neither need to pull in unnecessary dependencies. Also, the more code and more dependencies, the more liability.
Sometimes, dependency on very maintained code can be worse, than on unmaintained code. Breaking changes, and introduction of bloat (= functions and dependencies I don't need, but aren't optional to include them),... well, not my cup of tea, anymore.
I realized, I truly only need PDF output, and that I'm perfectly fine with gofpdf, which should work for long,.. and, if not, I could fork it and fix little issues. Or, I could create interface covering gofpdf's drawing api and implement a custom backend, later. Or, I'll rework it with some other PDF-library which will supersede gofpdf and get very adopted.
So, I was over-thinking the problem and over-engineering the solution,.. inventing problems, that I don't have, and most-likely won't have. In software, one wants features solving real problems and adding value, and less code and dependencies for less liability