byronbytes
CHORE: Improve versioning system
The system for how updates are rolled out are unpredictable and inefficient. Tasks is still in a preview version of 5.0.0 with countless updates not helping for future development. Major releases are released too quickly, with 4.0.0 only lasting 1 version.
What I propose for the new update system is to have two branches. Stable and Beta. Beta updates will release faster than stable, and will be on GitHub for everyone to test. You will also be able to change the branch in the app and get automatic updates through there.
There have also been issues with stabilizing and rolling out updates, which I had mentioned earlier. This can be switched to a new way of releasing updates. Instead of having to do incremental updates (major.minor.patch), it can be switched to (moth.day.year) or (major.minor.patch.build).
could adopt a 0. version or denominators for test versions before release, and then use numeric versioning for the finish product. so for example Tasks build mmyybb (example tasks 5 build 092306) or Tasks 1 RC1, and then Tasks (or tasks 1.0) for the finish product.
could adopt a 0. version or denominators for test versions before release, and then use numeric versioning for the finish product. so for example Tasks build mmyybb (example tasks 5 build 092306) or Tasks 1 RC1, and then Tasks (or tasks 1.0) for the finish product.
I like the idea of the build versioning system. I'm not sure if we can do the 0. versioning system if we're already at 5.0. Speaking of the builds, how would you even track the number? As you said month/year/build, but would it define how many times I debugged it? Made a change? Ran it? I would like more context to that.
Release Candidates would somewhat make sense on beta versions that are about to be finalized / needs more testing since you can use that anywhere.
could adopt a 0. version or denominators for test versions before release, and then use numeric versioning for the finish product. so for example Tasks build mmyybb (example tasks 5 build 092306) or Tasks 1 RC1, and then Tasks (or tasks 1.0) for the finish product.
I like the idea of the build versioning system. I'm not sure if we can do the 0. versioning system if we're already at 5.0. Speaking of the builds, how would you even track the number? As you said month/year/build, but would it define how many times I debugged it? Made a change? Ran it? I would like more context to that.
Release Candidates would somewhat make sense on beta versions that are about to be finalized / needs more testing since you can use that anywhere.
builds defined by how many times you compile it.
you can do a bata veshon
On Fri, Sep 8, 2023 at 7:02 PM miaugato93 @.***> wrote:
could adopt a 0. version or denominators for test versions before release, and then use numeric versioning for the finish product. so for example Tasks build mmyybb (example tasks 5 build 092306) or Tasks 1 RC1, and then Tasks (or tasks 1.0) for the finish product.
I like the idea of the build versioning system. I'm not sure if we can do the 0. versioning system if we're already at 5.0. Speaking of the builds, how would you even track the number? As you said month/year/build, but would it define how many times I debugged it? Made a change? Ran it? I would like more context to that.
Release Candidates would somewhat make sense on beta versions that are about to be finalized / needs more testing since you can use that anywhere.
builds defined by how many times you compile it.
— Reply to this email directly, view it on GitHub https://github.com/byronbytes/Tasks/issues/77#issuecomment-1712317816, or unsubscribe https://github.com/notifications/unsubscribe-auth/AWMUHXXFRTT54KS6J6XDYBDXZOPWZANCNFSM6AAAAAA4NIPDEY . You are receiving this because you are subscribed to this thread.Message ID: @.***>
you can do a bata veshon … On Fri, Sep 8, 2023 at 7:02 PM miaugato93 @.> wrote: could adopt a 0. version or denominators for test versions before release, and then use numeric versioning for the finish product. so for example Tasks build mmyybb (example tasks 5 build 092306) or Tasks 1 RC1, and then Tasks (or tasks 1.0) for the finish product. I like the idea of the build versioning system. I'm not sure if we can do the 0. versioning system if we're already at 5.0. Speaking of the builds, how would you even track the number? As you said month/year/build, but would it define how many times I debugged it? Made a change? Ran it? I would like more context to that. Release Candidates would somewhat make sense on beta versions that are about to be finalized / needs more testing since you can use that anywhere. builds defined by how many times you compile it. — Reply to this email directly, view it on GitHub <#77 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AWMUHXXFRTT54KS6J6XDYBDXZOPWZANCNFSM6AAAAAA4NIPDEY . You are receiving this because you are subscribed to this thread.Message ID: @.>
I definitely plan on it
what about bata ver
On Mon, Sep 11, 2023 at 10:03 AM Byron @.***> wrote:
you can do a bata veshon … <#m_4201941241927923098_> On Fri, Sep 8, 2023 at 7:02 PM miaugato93 @.> wrote: could adopt a 0. version or denominators for test versions before release, and then use numeric versioning for the finish product. so for example Tasks build mmyybb (example tasks 5 build 092306) or Tasks 1 RC1, and then Tasks (or tasks 1.0) for the finish product. I like the idea of the build versioning system. I'm not sure if we can do the 0. versioning system if we're already at 5.0. Speaking of the builds, how would you even track the number? As you said month/year/build, but would it define how many times I debugged it? Made a change? Ran it? I would like more context to that. Release Candidates would somewhat make sense on beta versions that are about to be finalized / needs more testing since you can use that anywhere. builds defined by how many times you compile it. — Reply to this email directly, view it on GitHub <#77 (comment) https://github.com/byronbytes/Tasks/issues/77#issuecomment-1712317816>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AWMUHXXFRTT54KS6J6XDYBDXZOPWZANCNFSM6AAAAAA4NIPDEY https://github.com/notifications/unsubscribe-auth/AWMUHXXFRTT54KS6J6XDYBDXZOPWZANCNFSM6AAAAAA4NIPDEY . You are receiving this because you are subscribed to this thread.Message ID: @.>
I definitely plan on it
— Reply to this email directly, view it on GitHub https://github.com/byronbytes/Tasks/issues/77#issuecomment-1713954808, or unsubscribe https://github.com/notifications/unsubscribe-auth/AWMUHXUPBROH4XQRWYRDJ6TXZ4KZRANCNFSM6AAAAAA4NIPDEY . You are receiving this because you commented.Message ID: @.***>
-- This is a student email account managed by New Paltz Central School District. The contents of this email are governed by the laws of the state and the board policies of the school district.