You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Among the many planned features of Stacks 2.1 is upgrades for a few different elements of the system, e.g.,
A new Clarity release, with new native functions.
A new PoX contract, with new functionality, fixes to old functionality
For many of these, we need a way to reference the new version of the element vs. the old version. For PoX, the published contract won't be named pox, but instead something else, e.g., pox-2. For Clarity, the "versioning pragma" has to be able to specify which version of Clarity a new contract should be evaluated with.
These versions could be set to "2.1", such that the new PoX is pox-2-1. Or these versions could be set to "2", because they are the second versions of these new elements. From a technical standpoint, the second option may make more sense, because future Stacks network upgrades may not upgrade these same elements again, such that a Stacks 2.2 release is using, e.g., PoX 2.1. But, having multiple versions for these elements could be confusing (i.e., documentation explaining a function is available only in "Clarity 2" versus "Stacks 2.1").
I'm pretty ambivalent about this -- mostly because I think I have a pretty bad instinct for naming and versioning, so would be happy to go along with something that people felt strongly about. But I do think that this is something we should decide on now, before messaging about future changes becomes ingrained.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Among the many planned features of Stacks 2.1 is upgrades for a few different elements of the system, e.g.,
For many of these, we need a way to reference the new version of the element vs. the old version. For PoX, the published contract won't be named
pox
, but instead something else, e.g.,pox-2
. For Clarity, the "versioning pragma" has to be able to specify which version of Clarity a new contract should be evaluated with.These versions could be set to "2.1", such that the new PoX is
pox-2-1
. Or these versions could be set to "2", because they are the second versions of these new elements. From a technical standpoint, the second option may make more sense, because future Stacks network upgrades may not upgrade these same elements again, such that a Stacks 2.2 release is using, e.g., PoX 2.1. But, having multiple versions for these elements could be confusing (i.e., documentation explaining a function is available only in "Clarity 2" versus "Stacks 2.1").I'm pretty ambivalent about this -- mostly because I think I have a pretty bad instinct for naming and versioning, so would be happy to go along with something that people felt strongly about. But I do think that this is something we should decide on now, before messaging about future changes becomes ingrained.
Beta Was this translation helpful? Give feedback.
All reactions