Change the version scheme

[BeepBot99]

What problem were you having?

No response

What solution would you like?

Move 1.1.0 from August 2024 to January 2025. Note that August 2024 would still happen, it just wouldn't be when the features in 1.1.0 are released. This is just a suggestion, you don't have to do it, I just think it might be nice.

What alternatives have you considered?

Keep the release of Twelve of Code 1.1.0 in August 2024.

What are some pros and cons of doing this?

Pros:

• There is more time to develop 1.1.0.
• We can add even more awesome features to 1.1.0.
• We can say that we will release a new version in January of every year.
• It is more time for people to learn about Twelve of Code.

Cons:

• It will take longer for some cool features to be released.
• People will have to wait for longer.
• We might finish early and not have anything to do for a while.

What page is this for?

Twelve of Code

[Mesure73L]

How about this:

• Every year, there is a major release (April 2024 would be 1.0.0, January 2025 would be 1.1.0, etc.)
• Every month, there is a minor release (August 2024 would be 1.0.1, Febuary 2025 would be 1.1.1, etc.)

[Mesure73L]

That way, we could still make features for August 2024, but one major update per year.

[BeepBot99]

I like that, but not a minor release every month, only when we want to. Also, how about instead of 1.1.0 it is 2.0.0? Then, we can have major releases, minor releases, and builds.

[Mesure73L]

How about this:

• One major release for every year
• Minor releases for every month
• Builds whenever we want

[BeepBot99]

Are you a very amazingly smart person? It goes major.minor.build

[Mesure73L]

My bad, thanks for informing me politely.

[BeepBot99]

Wait so anyway is this suggestion accepted?

[Mesure73L]

Please be kind with your comments. /srs

[Mesure73L]

Calling people idiots is not nice

[BeepBot99]

Wait so anyway is this suggestion accepted?

You're so mad you didn't even read what I said.

[Mesure73L]

Wait so anyway is this suggestion accepted?

You're so mad you didn't even read what I said.

I did, I just decided to ignore it because you don't know how to be respectful.

[Mesure73L]

So is my idea good?

[BeepBot99]

How about this:

1. It starts at 1.0.0
2. Minor releases whenever we want, like for a single feature. A minor release would go from 1.1.0 to 1.2.0. Minor releases, when released, are always released on the first of a month.
3. Major releases every year. So, it would go from 1.0.0 to 2.0.0.
4. Builds for bugfixes. So, it would go from 1.0.0 to 1.0.1.

[Mesure73L]

How about this:

1. It starts at 1.0.0. (Initial release)
2. Minor releases on the first of every month.
   1. Minor releases can be as big as a completely new feature or as small as just making the challenges.
   2. Minor releases only release on the first of every month.
3. Major releases every year.
   1. Major releases only release at the start of the year.
   2. Same things from minor releases apply.
4. Builds for bugfixes or small features that don't affect the challenge very much but are good to have (QoL features).
   1. Builds should not be very big.
   2. Builds can be released whenever.
   3. Examples of things builds can have:
      • Bugfixes
      • Challenges (if we can't make all 3 in time)
      • Small features (e.g. new setting that doesn't affect the challenge very much)
      • Typo fixes
      • Any other small thing

Exceptions can be made, for example if we have a big feature that we want to release we can release it in a minor release. Minor releases in these exceptions should be on the day that a challenge is released, to keep it more organized.

[BeepBot99]

No, I think challenges being released should always be builds instead of minor releases unless there is a minor release at the same time. Other than that, it is good.

[Mesure73L]

No, I think challenges being released should always be builds instead of minor releases unless there is a minor release at the same time. Other than that, it is good.

Oh yeah, I forgot to remove that from the minor releases, my bad. This is the official Twelve of Code version scheme now.

[Mesure73L]

Oh nevermind, in that I meant like the challenges that we make at the start of the month. Mid-month challenges will be builds.

[BeepBot99]

No, what I'm saying is it only goes from 1.0.0 to 1.1.0 if features are being released other than challenges. If only challenges are being released, no matter when they are, then it should go from 1.0.0 to 1.0.1.

[Mesure73L]

No, what I'm saying is it only goes from 1.0.0 to 1.1.0 if features are being released other than challenges. If only challenges are being released, no matter when they are, then it should go from 1.0.0 to 1.0.1.

I don't agree with that. I think to make it more organized, we should have the first of every month be a new minor update.

[BeepBot99]

If you care about organization, how about challenges just aren't any update? If you want a comparison, it is like the Minecraft marketplace. There isn't a new Minecraft update every time there is a new thing on the marketplace.

[Mesure73L]

No, every time Twelve of Code changes there will be some type of update. Minecraft marketplace is (probably) connected to a database to get everything on the marketplace, and so it doesn't need a new update because the only thing that changed is the list on the database. Twelve of Code challenges will be added to the code, therefore it needs an update.

[Mesure73L]

If you want to make comparisons, please make comparisons that are actually fair.

[BeepBot99]

You can do whatever you want. This is your challenge, and you have the final say. However, I do think there should be some way to differentiate between challenges being released and an actual update to the experience. I think challenges being released should be independent to updates actually updating the website.

[Mesure73L]

You can do whatever you want. This is your challenge, and you have the final say. However, I do think there should be some way to differentiate between challenges being released and an actual update to the experience. I think challenges being released should be independent to updates actually updating the website.

I think if there's something changed in the code that would not make it the same as it would be in the previous "version" there should be an update for it. If we hard-code all of the challenges (like we've been doing) then there should be a new update for it.

[BeepBot99]

We're not hard-coding the challenges anymore. The version should now be independent of challenges.

[BeepBot99]

What about this? And maybe you could have a tooltip when you hover over it that says "Twelve of Code 1.0.0, released on April 1st, 2024"

[BeepBot99]

I know this should go in #84 but I really don't care, this is about the version too.

[Mesure73L]

Make it say "Version 1.0.0" (optional, but still see how it looks) and make the tooltip just say "Released on April 1, 2024" because if you add "12oC 1.0.0" then thats redundant information.

[BeepBot99]

Okay, I can do that. Should I make it instead of you then, because you were assigned to #84?

[Mesure73L]

Sure