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.
-
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