-
Notifications
You must be signed in to change notification settings - Fork 767
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
Tracking Issue for 4.1 Release #121
Comments
I think that using "milestones" is a much clearer way to keep track of pending issues before a new release... And there is already one for 4.1, so, should this one be closed? |
Milestones does not have a comment function. Also this method has been adopted by other large projects as well. |
Instead of commenting on every issue to track, we should instead link to issues here, as well as tag each of the linked issues with the GTSAM 4.1 milestone. |
This model is borrowed from Rust, where you just use comment commands to manage issues and Tracking issues. Difference is that they have a bot that automates this process and we currently do not. |
@ProfFan is in charge of 4.1 and I defer to him as to what model to use... |
But this affects how we do things going forward. If everyone uses a different model for release cycles when they have control, we're going to end up with code smell like the kind we saw over the summer (students in a rush to graduate, etc). |
Ohhh, that sounds sooo familiar... It's sad to see that it's a universal thing in Academia |
First sorry to everyone for being a bit aggressive on making changes here. I agree with @varunagrawal on the release cycle part. However this has nothing to do with release cycles :) Similar situations happen all over the open source software community, which is exactly the the thing that I am trying to prevent. In larger organizations, a Request-For-Comments (RFC) based flow has been established for quite a long time, where people draft RFCs that contains all the rationale for a new function or breaking change, and all devs vote for merge or not merge. We are smaller so IDK if that is too much hassle. |
Ok, now 4.0.3 is pretty much ready? We should clean up this issue: IMHO it should just be the pybind wrapper in 4.1 as well as Removing deprecated methods/functions. |
add6075e8 Merge pull request #121 from borglab/feature/constructor-templates 42d4145bb update instantiate_ctors to handle constructor level templates 455ce6169 update test fixtures 3c37fc2a0 update wrapper test fixtures ffdad925d update interface_parser to pass the tests bf7416213 add interface_parser test for templated constructor 9fe05d0c9 Merge pull request #120 from borglab/feature/templated-namespace 7622e6432 typo fix 88779c5e6 update instantiator to handle templates in the namespace 0ee86f9a3 add test for templated type in namespace git-subtree-dir: wrap git-subtree-split: add6075e8ec0e28d5f47d0a2ecab00deaa9a3da7
We are planning a 4.1 release, and this is the tracking issue to gather insights and feedbacks on that.
The text was updated successfully, but these errors were encountered: