Overall architecture / adbackup todos

[SailReal]

Todos for adbackup

• core
  • make adbackup usable as module and cli tool split adbackup.rs into module and cli tool #9
    • define api interface (should be consistent between module and cli)
• device connection
  • list available devices list available devices #4
  • wrap backup/restore commands Implement backup/restore commands #12
  • list available apps to backup on device Implement backup/restore commands #12
• backup/restore options (adb)
  • with system applications
  • with data
  • sd card
  • single app with data
• data handling
  • pack/unpack backup Pack/unpack backup #13
  • define how to store data to make incremental backups possible (database) store backups in sqlite database #6
  • store data and apps
• documentation
  • preconditions (install adb, enable debug mode etc) Preconditions for using adbackup #18
  • how adbackup works how adbackup works #16
• frameworks
  • include failure Add https://github.com/withoutboats/failure as dependency #1
  • include log add log as dependency https://docs.rs/log/0.4.0-rc.1/log/ #5

[DonatJR]

should we assign a milestone to this issue? maybe "1.0.0-feature-complete" or "1.0.0-alpha" or something?

[DonatJR]

also, is it okay if I do the split between lib and cli tool? (core - make adbackup usable as module and cli tool)? @SailReal

[SailReal]

Yea...hmm would say only 1.0.0?
We can define in an other step and location what the 1.0.0 is (alpha, beta, or release candidate...)...right?

...if I do the split between lib and cli tool? ..

For sure, go for it 👍

[DonatJR]

Yea...hmm would say only 1.0.0?

1.0.0 alone would not be 100% correct in my opinion as this issues just lists features and architecture goals. a 1.0.0 milestone should be the 'whole thing' which this issues does not represent (this is why we changed the title to "overall architecture [...]")

We can define in an other step and location what the 1.0.0 is (alpha, beta, or release candidate...)...right?

isn't an alpha / beta / rc an unfinished state of a major version? I think the convention is to have a 1.0.0-alpha which is feature complete, a 1.0.0-beta which is relatively bug free and a 1.0.0-rc which is the finished state but still needs testing. if the tests are successful the rc then gets released as 1.0.0.
we can also have a 0.9.0 (for example) as alpha, 0.9.5 as beta and so on - I don't really care either way but I think the first pattern is more common

[SailReal]

I think we actually started two discussions: What is the milestone of this issue and what is our versioning strategy.

What is our versioning strategy
The version for Jan/Feb should be a release afaik (think that was required by the lecture)...in my option 1.0.0? To make some earlier versions would be nice to represent the dependencies for the tasks but I think that would be too much overhead...so we should assign all other issues to version 1.0.0?

What is the milestone of this issue:
For this issue maybe no milestone is needed because all tasks referenced here already have milestones...

[DonatJR]

we don't have any milestones configured yet, how can all tasks already have milestones? but yeah, let's just use 1.0.0

[SailReal]

...so we should assign all other issues to version 1.0.0?

I meant that all other issues than this one should have version 1.0.0.
Ok nice, will create the milestone and assign the tasks...

[SailReal]

As disscussed, I will implement #12 (implement backup/restore commands) in the next few days... btw happy 🎄🎁 ☃️

[SailReal]

Will later start with describing the preconditions for adbackup: #18