Hi,
Thank you for sharing the additional links and your inputs. I want to
confirm that based on my understanding Semantic Versioning helps indicate
the type of changes in a release(from user perspective - in case of option
two of version format), but unique identification of release artifacts
On Tue, Nov 19, 2024 at 9:56 AM Vahila wrote:
> Thank you for sharing the additional links and your inputs. I want to
> confirm that based on my understanding Semantic Versioning helps indicate
> the type of changes in a release(from user perspective - in case of option
> two of version format),
By the way https://github.com/jenkins-infra/jenkins.io/pull/7686 should
help clarify some things.
--
You received this message because you are subscribed to the Google Groups
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci
On Thursday, November 14, 2024 at 5:49:49 AM UTC-5 Vahila wrote:
Q1. Our plan is leverage CD but to trigger the release explicitly, not on
every push.
That would not be “CD” would it?
In the version format, is it okay to have only a manually controlled
semantic version(ex: 4.2.34) and not
Thank you for your inputs! I have few follow-up questions.
Q1. Our plan is leverage CD but to trigger the release explicitly, not on
every push. In the version format, is it okay to have only a manually
controlled semantic version(ex: 4.2.34) and not append the ${changelist}.
Would we be able
On Wed, Nov 13, 2024 at 2:46 PM Vahila wrote:
> *Q1. Release Triggering:* My understanding is that every successful build
> of the default branch triggers a release
>
If at least one PR with an “interesting” label (so for example `bug` but
not `dependencies`) has been merged since the last releas
