Replies: 6 comments 2 replies
-
I think this is a good idea. We would have to make the release support it. |
Beta Was this translation helpful? Give feedback.
-
Also something to note is that for upgrading to the dynamic plugin version 1.3.0 we will have to drop the |
Beta Was this translation helpful? Give feedback.
-
Yeah, as Howard suggested i am agree with just keeping the tag as |
Beta Was this translation helpful? Give feedback.
-
About the timeline, should we do this for the first version ? Because that would require a new PR (to update the github action) Or do we postpone this for the next release? |
Beta Was this translation helpful? Give feedback.
-
Aligning with the operator and being consistent will be important from an automation point of view, so as indicated above it's a matter of when. As the existing tag built successfully but experienced a push failure when attempting to push to the container registry maybe the thing to do is to update from v0.1.0 -> 0.1.0 now and then ensure that 0.1.0 gets pushed correctly to the registry for general consumption. |
Beta Was this translation helpful? Give feedback.
-
This is resolved. Thanks @howardgao for proposing this change. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Currently there are two popular naming conventions for tag names. One is --<micro/patch-version> the other is prefix the previous one with a
v
.For example tag for version 0.1.0 could be
0.1.0
orv0.1.0
.Which one should be used? I'd suggest we use the first one (
0.1.0
) to be consistent with other artemiscloud projects, such as the operator https://github.com/artemiscloud/activemq-artemis-operator/tagsBeta Was this translation helpful? Give feedback.
All reactions