Incremental roadmap about boats-animator HOT 25 CLOSED

I moved the roadmap to a spreadsheet:

https://docs.google.com/spreadsheets/d/1PaP-foCy83l6-VGcRsOwH5pro-p7uPCX1TsxWOUWEvg/edit?usp=sharing

from boats-animator.

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

from boats-animator.

This seems a much better approach compared with the slightly random current one.

from boats-animator.

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

from boats-animator.

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). :)

from boats-animator.

Aha that's absolutely fine! Last week was a school holiday for me and as a result I was far more active then normal.

from boats-animator.

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

from boats-animator.

I'll get right on typing it up.

from boats-animator.

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).

Boats Milestones.docx

from boats-animator.

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.

from boats-animator.

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.

from boats-animator.

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. ;)

from boats-animator.

@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.

from boats-animator.

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:

• THAC is coming up. Wouldn't it be nice to know people could use Boats Animator for their THAC film instead of HeliumFrog?
• Camera resolutions are a tricky thing. There are a ton of cameras out there, and while the JS API abstracts a lot of the messy, complicated bits, there is still stuff on our part to make sure it is compatible with cameras and high resolutions. The only way we can do that is through mass testing and usage.
• While projects are a key app feature, they are not necessary for resolutions and implementing them afterward would not create an issue. We have the global save path already and it works. Lack of frame imports would be a bigger issue than projects if we had a version that could be used for THAC.

Those are my reasons for reassigning camera work to 0.7.x instead of 0.8.x.

from boats-animator.

Your reasons seem pretty sound, I'm happy to move the camera work ahead of projects.

THAC is coming up. Wouldn't it be nice to know people could use Boats Animator for their THAC film instead of HeliumFrog?

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.

Those are my reasons for reassigning camera work to 0.8.x instead of 0.7.x.

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.

from boats-animator.

I've just updated the roadmap on Google Drive:

• Links have been added to the related issues
• Project work has been moved to 0.8.x and camera work to 0.7.x
• The new notifications system has been moved to 0.7.x

from boats-animator.

Oh yes, I would like to have editing rights, please. :)

from boats-animator.

Okay, I've added you! :)

from boats-animator.

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.

from boats-animator.

@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 0.7.0-beta1 or 0.7.0.1? (http://semver.org/ seems to suggest so)

from boats-animator.

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?

from boats-animator.

@le717 I think I understand - we have a system that seems to work, it's just not Semver.

Also one more thing I forgot: I think it would be good to add #71 to 0.7.0, more so than #60 and #61. I think it would be a nice fit after keyframes are added.

from boats-animator.

For 0.7.0, I propose the following features be implemented:

• #108 (nwjs 0.13)
• #135 (WebRTC API updates)
• #136 (Revised playback methods)
• Maybe #137 (I say yes, but I'm trying to think what else we'd have for the release series and if this would want to be held back for 0.7.1)

from boats-animator.

What would you think about... resolutions and camera selection being pushed to 0.8.x?

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.

from boats-animator.

@le717 I've moved the camera work and added a few missing issues.

from boats-animator.