Overall architecture / adbackup todos

[SailReal]

Todos for adbackup

• core
  • [x] make adbackup usable as module and cli tool #9
  • [x] define api interface (should be consistent between module and cli)
• device connection
  • [x] list available devices #4
  • [x] wrap backup/restore commands #12
  • [x] list available apps to backup on device #12
• backup/restore options (adb)
  • [x] with system applications
  • [x] with data
  • [x] sd card
  • [x] single app with data
• data handling
  • [ ] pack/unpack backup #13
  • [x] define how to store data to make incremental backups possible (database) #6
  • [x] store data and apps
• documentation
  • [x] preconditions (install adb, enable debug mode etc) #18
  • [ ] how adbackup works #16
• frameworks
  • [x] include failure #1
  • [x] include 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