Make it easier to migrate Echo to a new year #6803
Conversation
This year you made everything from scratch in a very short period of time. I understand you don't want that again. But I'm afraid that automatically publishing this every year might actually have the opposite effect: because it will get published automatically we will have/want to make changes, even if we realise this late. If we don't do them, it will be visible again with bugs or imperfections. I would rather take the manual approach, where each year we make a decision to work on it in time or not. And then if we do, implement changes over, let's say, October, and release in November. |
keunes
added
the
Needs: Decision
|
The problem with "work on it on time" is that it still requires us to publish an update at a specific point in time. Even if we start it in August, we still have to make sure to get it released in time. So let's start right now and finish AntennaPod Echo 2024 in Jan/Feb. Then it's not as stressful as this year. What do you think we should change? |
Sure!
Shall I create one or more tickets? Some might be easier to implement than others… (i.e. some might be in another PR, or for 2025) |
|
I think one ticket with a checklist should be enough. These are probably rather small changes, I guess |
Also, add a new screen background
ByteHamster
force-pushed
the
echo-2024
branch
from
a7ecbf9
to
c6be58e
Compare
ByteHamster
changed the title
ByteHamster
removed
the
Needs: Decision
|
I doubt that all will be small changes, but I'll create a ticket for it - let's see :-) |
|
Sorry, if we take this approach, can we then remove the automatic publishing of Echo? That was the whole point of starting work on Echo right now. |
|
I changed the PR to be easier to update to a new year, no longer automatic |
|
Sorry, I didn't see another commit so I assumed, shouldn't have. |
Also, new screen background with expanding circles (waves) from the bottom, replacing one of the 2 stripes screens