Incremental roadmap #62
Comments
|
This seems a much better approach compared with the slightly random current one. |
|
I'd like to keep the releases pretty up to date with the source code for the sake of testers. My understanding is that the difference between release v0.6.0 and the current source in the main branch would only warrant a 0.0.1 version number increment. EDIT: Released current source as v0.6.1 |
|
Apologies for suddenly dropping out on you. You understand how life happens (hopefully). I am hoping to prepare some patch for you this weekend (we'll see). :) |
|
Aha that's absolutely fine! Last week was a school holiday for me and as a result I was far more active then normal. |
|
I'd like to get this written up (with additions) so we can work with a proper plan in place. Using Google Sheets seems the best approach IMO |
|
I'll get right on typing it up. |
|
Sorry about the delay, I am in finals right now. Here is a typed (and mostly up-to-date) roadmap. Obviously anything can change and version series (0.6 series, 0.7 series) numbers is not totally right. Consider anything 0.9.x+ WIP and unstable (we need to closer to those to better plan). |
|
IMO, the resolution changing (at least, filming in a proper resolution besides the tiny picture currently taken) is our TOP priority. Basically, Boats Animator would be production ready if it just took proper pictures. Next would be selecting and onion skinning, then comes the projects. |
|
Thanks for writing this up @le717! @rioforce I agree in terms of new features that need to be added resolution selection is probably one of the most important, however I imagine that such a feature would be affected by the projects system, making it better to introduce that first. Also I'm not exactly how to explain it but I see the projects system as more integral to the core of the program rather than being an additional feature and hence it should have a greater priority. I'd love BA to be production ready ASAP however I feel that doing things properly and having a solid foundation first is far more important. There are certainly 'other' programs that have rushed out important features to very little benefit. As long as things keep moving along here within a fairly reasonable time frame I'm not too concerned about BA being production ready for awhile. |
|
Well, the way I see it, we could get people to test the vital parts of the program (capture with proper resolution, playback, etc), while we get projects integrated. Basically, projects won't change the program that much, it's basically just save paths. That's the way I see it anyway. You have the final say of course. ;) |
|
@rioforce I see what your saying, to be honest I'm not really sure of which way round is better. I'd be interested to hear from @le717 to why he put the projects system ahead of camera and resolution selection. I really need to get round to displaying the new feature roadmap somewhere more prominent and accessible. |
|
I put the projects system ahead of camera because 1. I needed to do research on it and 2. I have experience with mass file listings, so I knew I could code that. However, I've since looked it up and toyed with it and I'm with @rioforce on this one. Let's move camera before projects. Here are my reasons:
Those are my reasons for reassigning camera work to 0.7.x instead of 0.8.x. |
|
Your reasons seem pretty sound, I'm happy to move the camera work ahead of projects.
That would be very nice indeed! If you think it's realistic, I'd like to see us aim to get a substantial amount of 0.6x and 0.7x's features out by then. I feel it is rather optimistic though.
You made a typo here I assume! 😉 I've said before, the roadmap is a bit hidden away here. I've uploaded it to Google Drive to make editing it easier. https://docs.google.com/document/d/1UgcyhNkvyirI4gy9uSVv-lD5q6sHe_FEAM-AFTBkyCs/edit?usp=sharing If you @le717 and @rioforce are willing to give me your Gmail addresses I'll give you editing rights. Alternatively the roadmap could be displayed on a wiki page here in the GitHub repo if you think that would work better. |
|
I've just updated the roadmap on Google Drive:
|
|
Oh yes, I would like to have editing rights, please. :) |
|
Okay, I've added you! :) |
|
OK, so what milestone are we on right now? The 0.6.x milestone currently sits at 100% and it looks like we finished our 0.6.x roadmap. I can't push my camera code now as I am out of a laptop (possibly all month) so that aspect of the 0.7.x series is blown for now. However, you are working on some major changes that could qualify for moving to the next release series. |
|
@le717 That is a good question. I suggest once your Add new utils module #126 and my status bar PR #125 have been merged we release v0.6.4 and move to 0.7.x The keyframes code should be added to the v0.7 milestone. Since #65 and #77 have already been implemented should I move them from 0.8.0 and 0.7.0 respectively to 0.6.0 on the roadmap? I'd like to move forward #60 and #61 to 0.7.0 since they look like something I could have a go at. Also my initial thoughts are that they would be part of the same feature. Finally, am I currently incrementing version numbers correctly? Semantic versioning says version numbers should be major.minor.patch and my interpretation of patch is bug fixes. Would it be better to not release, say 0.7.0, until all of the features on the roadmap are implemented? Or should we release an incomplete 0.7.0 with a postfix such as |
|
First two points: I agree with those. I have already updated the milestones for those two issues. I'm not so sure if that's good. I'll leave a comment on the appropriate issue, but it might be best to hold off until after resolutions. We could still move them to 0.7.x though. Semver is tricky and I still don't fully understand it. The fact is we have not followed it so far. I structured the milestones to be a group of series. 0.7.0, for example, would have one or two of the big features and other smaller changes. 0.7.1 might be just fixes and refinements. 0.7.2 might have only the next big feature. As you can see, everything would not have to immediately in place in order to bump the minor. Then, once all planned changes for that series, big and small, were implemented, we'd go to 0.8.x and restart the process. We've actually been following this with each 0.6.x release (see: UI redesign). Does that make sense to you? |
|
For 0.7.0, I propose the following features be implemented:
|
I was not expected the nwjs upgrade or my laptop to break, so moving camera work back to 0.8.x is good with me. |
|
@le717 I've moved the camera work and added a few missing issues. |
|
I moved the roadmap to a spreadsheet: https://docs.google.com/spreadsheets/d/1PaP-foCy83l6-VGcRsOwH5pro-p7uPCX1TsxWOUWEvg/edit?usp=sharing |
|
Moved the road map to a another new spreadsheet. This time things are more clearly divided into whether they are TODO, in progress or implemented. Also since the road-map, well, exists and has for a while I don't think this particular issue needs to stay open. https://docs.google.com/spreadsheets/d/17_2srr17qutcjEyvzINK2j4vL4EfNIUBU4KbbX8NHH0/edit?usp=sharing |
Feature Roadmap on Google Docs
I see you have been revising the roadmap but it only accounts for the major features. Further, we need something more incremental to go on to guide us one release at a time. So this morning I drew this up (I will have to transcribe it later):
Red means high priority, green medium, and blue low. Basically, it would guide us through each release, mapping out the currently known plans (as well as ones yet to be filed) and when they would be fixed/implemented. After 0.8.0 things started getting vague and I did not get the time to finish planning it out.
You will notice that the low priority listings for 0.7.0 and 0.8.0 became the next release high priority points. I did this to help gear the work towards the next major milestone. Initial work would begin on a branch sometime while that release was being developed. This branch (or even many branches trying out different ways of doing things) would ideally be cut from the last tagged commit and not updated with
masterchanges in order to have it focus solely on the intended feature. It could then go through code review and planning as it was being developed. Then, when the release the feature is slated to be released in came around, the (best) branch would receive the main focus, getting prepped up and merged withmasterso it would be ready for it's debut.I also tried to keep major changes to their own releases. Projects will be huge, so it gets 0.7.0. Resolution/camera gets 0.8.0. Takes get 0.9.0, etc.
Obviously this is all an idea, out of date (I think you may have solved the vague 0.9.0/1.0.0 releases...) and up for discussion, and smaller items could be released in patch updates (e.g., 0.6.1) but I am throwing it out here anyway because we need a plan. :P
The text was updated successfully, but these errors were encountered: