-
Notifications
You must be signed in to change notification settings - Fork 122
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
Road to Asciidoctor 2.0.0 #391
Comments
Hi Not a blocker but is there any rational to not maintain backward compatibility? |
Ever since some of the ideas finally implemented in 2.0.0 where scheduled for 1.6.0, there has been a plan in the whole Asciidoctor ecosystem to introduce some changes that required breaking compatibility.
Just checked and this is not possible. Maven plexus just maps the XML to the Mojo pojo. You can define a Map property like we do with We could maintain the same configuration model, but there some current options that in my opinion are clearly wrong:
About the removal of I do agree that autocompletion is a nice feature, but is just 3 properties, and documentation + the maven-examples repo are available. Given you feedback I'll start writing the migration guide to the README. This will help me see better the impact. PS: Note more changes will come in the future. For example |
About plexus, you can inject the xml and parse it as you want so technically there is no blocker. Also not sure why it wouldnt be mapped in the pojo. In 1.5 you were already able to use attributes so there is no reason to consider it as breaking since it is the case since years. |
Good catch! I can give it a try for 2.0.0 and mark the options as deprecated to be removed at some point to make transition less traumatic. Fields in some IDE (at least IntelliJ) will appear highlighted and not valid though. |
Here is the full migration guide https://gist.github.com/abelsromero/263ae7703f4bc5efebbfd16d9e407c28. |
Here a few comments:
Long story short I don't think that the plugin should stick to the asciidoctorj API only, this is not how a MOJO is useful but it should enable the config to be as explicit and user friendly as possible so these breakage are against that IMHO and not justified technically as well - the code to not break is very localized and manageable in time. To illustrate that it is trivial to use gmaven-plus plugin to render yourself your document programmatically in an aligned way on asciidoctorj so the plugin value is to encourage good practises IMHO. The v2 proposal is against that IMHO. Any hope this decision get revisited before the release? |
Keeping the old fields for 2.0.0 is still on the table, at least for a RC (which is my current goal for today, more info at the end). But eventually I still think removing them is for the best and a major version change is a good opportunity. You are right these is not extremely hard to maintain and are not mandatory, but over the past years the plugin has introduced several quirks, some because things where not well though at the time, like the imagesDir default value. Others just because how configurations options/attributes relate to each other.
Right now I am focusing on release a RC with non-braking changes, that is:
|
If you don't agree with the change to |
Is there any idea when the currently published |
May sound as excuse, but I am on it now. I cleared my schedule 2 weeks ago and I am working on compatibilities issues with gem-maven-plugin. As soon as these are fixed I'll do the changes and release the asciidoctor-maven-plugin. |
Everything is ready, relase will be done during the weekend if nothing goes wrong. |
@abelsromero Incredible work on the 2.0.0 release! Congratulations! 🎉 🍻 |
It's been a while but let's roll the 2.0.0 asciidoctor goodies for maven too.
The plan is split in 2 steps
1. Release 1.5.8 version (DONE)
This is more of a farewell and check to make sure we don't miss anything.
This will be aligned with Asciidoctor 1.5.8.1 (+ testing of 1.6.x) and contain some minor fixes.
Due to AsciidoctorJ changes, this won't be compatible with AsciidoctorJ 2.0.x.
To be released today 30th March.
2. Release 2.0.0 version
It will contain the necessary changes to use AsciidoctorJ 2.0.x., thx @robertpanzer for doing most of the work here.
This will introduce non-backward compatible changes (see migration guide https://gist.github.com/abelsromero/263ae7703f4bc5efebbfd16d9e407c28) that have been stalled untill now.
The complete list is here: https://github.com/asciidoctor/asciidoctor-maven-plugin/milestone/14.
Most notably are:
imagesDir
andsourceHighlighter
options in favour of defining it in the<attributes>
section.templateDir
(now deprecated in Asciidoctor) bytemplateDirs
(List) (#265)To be released (ideally) tomorrow or day after unless there are objections
asciidoctor-maven-examples will be updated during the next week after release.
What next?
After initial 2.0.0 release a new way for the maven-plugin opens with adoption of semantic versioning independent from the other Asciidoctor modules it relies on (Asciidoctor and AsciidocotorJ).
This gives us the opportunity and responsibility to evolve at our own pace.
For example, features like using other Asciidoctor implementations (e.g. asciidoctor.js) are not that far. These will likely require changes in the configuration that will break backward compatibility. Thanks to the new versioning model we will be able to achieve that in a less intrusive way possible for users.
The text was updated successfully, but these errors were encountered: