| Re: [krazo-dev] Eclipse Krazo Roadmap |
Hey all,thanks a lot for your feedback. I guess we all agree that getting a release out under the new project name is top priority.Regarding release frequency: I don't think it is a real problem that the latest spec release is a few months old. There were only about 4 commits since then which only fixed typos and similar minor stuff. So there has been no change to the API since the pfd version. Of course, it would be great to push Krazo releases out more often. And I would be fine with doing this on a regular basis (perhaps once a month or every two weeks?). This should be easy, because releasing MUST be done automatically via Jenkins. I guess frequent releases work fine if no updates are required on the spec level (which I don't expect).However, I don't think we should release Krazo 1.0 before the spec is final. Especially because currently we don't fully implement the spec. Maybe we could update the naming scheme for the versions to emphasize that we consider Krazo to be almost final!?Please also note that I really would love to see the spec going final as soon as possible. That's why I'm working hard to finish the TCK which is the last big item on the TODO list (beside the work on Krazo of course). Therefore, it would be great to get some help on the Krazo side, so I can focus on the TCK.BTW: Of course any feedback from real world project would be great! Hopefully a success story! :-)ChristianAm Mo., 21. Jan. 2019 um 09:23 Uhr schrieb Gregor Tudan <gregor@xxxxxxxx>:Hey all,_______________________________________________+1 for a quick m05 release to get the new package prefix out in the wild.I agree that a 1.x should have a decent TCK-Coverage, so that might take a while. But the Snapshot (or milestone state) is a big show-stopper for many projects. This applies to Ozark as well as the Spec (which has been in PFD for quiet a while now). I think the project could definitely benefit from more real life projects. This would raise the interest and help getting more contributions.So maybe we could release a 1.0 once we stabilized the API and squashed the worst bugs from the issue tracker? Then we could work on the TCK compatibility in a couple of minor releases in quick succession (monthly?).- GregorAm 20.01.2019 um 15:40 schrieb Christian Kaltepoth <christian@xxxxxxxxxxxx>:_______________________________________________Hi all,I would like to discuss the roadmap for Krazo and what our short and long term goals are. I cleaned up the GitHub issue tracker a bit and created two "milestones" which I think make most sense. Please note that this isn't a final decision but a first draft. So feel free to suggest changes.Version 1.0.0-m05 (see open issues)This would be our first release under the EE4J umbrella. IMO we should push out the release as soon as possible, because people who don't want to use snapshots are currently forced to use the old Ozark builds.The first release of an Eclipse project is a very special release, because we are required to file CQs for all the third-party dependencies we are using. See the Intellectual Property chapter of the Eclipse Handbook for details. Ivar and I are already working on the CQs and tracking our progress in #30. I hope to find some time next week to finish the creation of all remaining CQs. Then it is up to the Eclipse legal team to approve them or not. We _may_ have to remove some of the extension modules if the Eclipse legal team tells us that their license is incompatible. But let's wait if this really happens or not.To sum up: IMO we should push out our first release as soon as all the CQs are approved.Version 1.0.0-m06 (see open issues)This release would be the next steps after 1.0.0-m06. IMO we should focus on:
- Address TCK compatibility issues. I'm currently working hard on finishing the TCK and we already have a coverage of over 65%. However, there are various issues that I found while working on the TCK and finding a solution for these issues should be top priority. Mostly, because these issues prove that we are not fully compatible with the requirements of the spec. I'll create some issues which more details about the individual problems in the next days and tag them accordingly. Please note that any help on this is welcome. Especially we now have an Arquillian-based test suite (thanks Gregor) which should allow creating corresponding tests very easily. And having a failing list is a great first step. :-)
- There are also some other existing issues in the issue tracker which are not directly TCK related. However, of course it would be great if we could fix as many of them as possible.
Please note that we don't have to fix all the issue I already assigned to this version before releasing it. But it would be great if we could fix as many of them as possible.Let me know what you think.Christian
krazo-dev mailing list
krazo-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/krazo-dev
krazo-dev mailing list
krazo-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/krazo-dev
--