Version numbers / Frequent release feedback #6507
Replies: 9 comments 5 replies
-
(or for example version 1.89.7b) |
Beta Was this translation helpful? Give feedback.
-
|
FWIW, I have the same issue myself for other packages, and I'm using a
letter-based sub-version number for my own changes. If you were to adopt
this, then in your case, say imgui releases 1.89.3, you release imgui.net
1.89.3a, and if you need to do some patches on it later, you'd release
1.89.3b, 1.89.3c, etc.
…On Fri, Jun 9, 2023 at 8:19 PM Zaafar.A ***@***.***> wrote:
2: in the new version system, is there a chance of using a, b, c? (for
example VERSION 1.33b (2015-02-23))
(or for example version 1.89.7b)
—
Reply to this email directly, view it on GitHub
<#6507 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABXRXJRP7DOB63NHI4W6AM3XKPRSJANCNFSM6AAAAAAZBMSMLE>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
yeah that's what i am thinking. |
Beta Was this translation helpful? Give feedback.
-
|
(unfortunately nuget (c# package manager) doesn't like 1.89.3a or 1.89.3b. |
Beta Was this translation helpful? Give feedback.
-
|
What I do in similar situations is just to have my versions fully separated from the library version and when I release a new version of the library I just include in the release notes which version of the library that has been updated to. Yes, users will have to read the release notes, but imo it's better as I'm allowed to change my lib version in any way I want. |
Beta Was this translation helpful? Give feedback.
-
|
On nuget, I'm using a 4th version number, so for example, 1.89.3.1,
1.89.3.2, 1.89.3.3, etc.
…On Sat, Jun 10, 2023 at 12:31 AM Daniel Collin ***@***.***> wrote:
What I do in similar situations is just to have my versions fully
separated from the library version and when I release a new version of the
library I just include in the release notes which version of the library
that has been updated to.
Yes, users will have to read the release notes, but imo it's better as I'm
allowed to change my lib version in any way I want.
—
Reply to this email directly, view it on GitHub
<#6507 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABXRXJSIC7XROD4UUB7AIS3XKQPF7ANCNFSM6AAAAAAZBMSMLE>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
yeah, I am going to use that as well. since that is working (Pushing ImGui.NET.1.89.5.1.nupkg to 'https://www.nuget.org/api/v2/package'...) thank you for all the feedback! Closing this discussion. FYI: @ocornut |
Beta Was this translation helpful? Give feedback.
-
To clarify a few things: Dear ImGui is not following semantic versioning. I don't believe it is appropriate for this project. So me adding that extra The truth behind this is: I wrongfully perceived the "xx" in "1.xx" as a % rate leading to 2.0. But this reasoning is flawed, after reading this thread I came to the realization it was perfectly fine to have 1.101, 1.102, 1.156 etc and not immediately go to 2.0. By this logic I think I probably make a mistake in my versioning and 1.89.1-1.89.6 could perfectly have 1.90-1.95. Depending on the status of range-select work I might adsorb that and not care about 1.90 being a particularly cool release. Either way, I think your own patching on a repackaged release should add an extra |
Beta Was this translation helpful? Give feedback.
-
Addenum: one issue with allowing 1.101 etc is the way we define We would need at one point to bump number of digits so 1.99 would be 19900 or 109900 (depending on when we bump) |
Beta Was this translation helpful? Give feedback.
-
Not saying we should do this but if you go the route of 1.101.2, the chances of reaching 1.101.9+ is low. So: 1.99.2 can be 010992 |
Beta Was this translation helpful? Give feedback.
-
|
That would break #if IMGUI_VERSION_NUM >= checks. |
Beta Was this translation helpful? Give feedback.
-
|
I see, good point. So basically let's continue with xx.yy.zz format. For now I am good with that since I can basically add xx.yy.zz.kk on my side to solve all my concerns. |
Beta Was this translation helpful? Give feedback.
-
|
Please please also don't use "Discussions" for this. It is stated in bold to not post there for such topic. I am surprised you intently went past that wall to post your meaningful message :) (Screenshot) |
Beta Was this translation helpful? Give feedback.
-
|
That is my bad! sorry. won't happen again. |
Beta Was this translation helpful? Give feedback.
-
While I really love the idea of frequent releases and want imgui to move in that direction. it have, unfortunately, created a minor issue for people like me who are releasing imgui.net (this might also be true for other language bindings).
==background==
At Imgui.net side we try to remain in-sync with the imgui version so, once 1.89.6 is released we will try to release imgui.net 1.89.6 as well. There were times when we got out-of-sync but we always try to bring it back to being sync. Due to this (unfortunately) we have to pay big price (e.g. new features/bug fixes/changes on imgui.net side might appear under a patch version)
== why old way worked for us ==
previously imgui didn't use patch versions a lot (e.g. after 1.86, there was 1.87, then there was 1.88 and so now) so we could use patch version for our own features/changes and once imgui releases a new minor version we could sync up again
== why new way is not working for us ==
Now imgui uses patch version (e.g. 1.89.1, 1.89.2 ... ) a lot so we can't use them for our features/bug-fixes/stuff :)
== Questions ==
1: is there a reason why we have started doing that? i.e. rely more on patch versions rather than minor versions?
2: in the new version system, is there a chance of using
a, b, c? (for example VERSION 1.33b (2015-02-23))Beta Was this translation helpful? Give feedback.
All reactions