>The cons seem more important than the benefits.
What are the cons?
>I don’t see why we need this
I've provided multiple cases that did happen in JMeter recently, and I
clarified how force-push would improve the things.
Could you please clarify "the cons"?
Vladimir
>Pushing more than your envisioned two or three version
Any committer can push "by accident" a lot of commits to the current master
branch.
Nothing prevents it.
If we enable force-pushes, it will be exactly the same.
Note: force-push does not happen automatically.
>Changed/changing git repos are
Am 6. Oktober 2019 14:15:30 MESZ schrieb Vladimir Sitnikov
:
>>the risk of accidentally changing history,
>
>What is the risk? Can you please clarify?
Pushing more than your envisioned two or three version.
Changed/changing git repos are harder to follow. I removed my github fork as it
was e
>the risk of accidentally changing history,
What is the risk? Can you please clarify?
Vladimir
Am 05.10.19 um 20:38 schrieb Vladimir Sitnikov:
>> First, If a forced commit is pushed, the subsequent commit email will
>> contain '[Forced Update!]' in the subject line
> The Board has decided force push could be allowed for development branches.
> However, our current master branch is protecte
>First, If a forced commit is pushed, the subsequent commit email will
>contain '[Forced Update!]' in the subject line
The Board has decided force push could be allowed for development branches.
However, our current master branch is protected.
I suggest we un-protect it.
This would enable:
1) Ro
On Thu, 3 Oct 2019 at 14:13, Vladimir Sitnikov
wrote:
>
> >Enough for what?
>
> For the project.
I still don't follow.
>
> Current tag names are like
> v4_0_RC7
> v5_0_RC1
> v5_0_RC2
> v5_1_1_RC1
> v5_1_RC1
> v5_1_RC2
>
> They do not follow the new "rel/*" naming
So?
The rel/* naming is intend
>Enough for what?
For the project.
Current tag names are like
v4_0_RC7
v5_0_RC1
v5_0_RC2
v5_1_1_RC1
v5_1_RC1
v5_1_RC2
They do not follow the new "rel/*" naming, so we need to invent the way we
would tag upcoming releases.
Vladimir
On Thu, 3 Oct 2019 at 12:45, Vladimir Sitnikov
wrote:
>
> sebb>What do you mean by validate?
>
> When we migrated from SVN to Git, Infra completely ignored tags in the Git
> repository.
> They did not care
>
> sebb>That was certainly how I read the Infra email.
>
> So is rel/v5.2.0 tag enough in y
sebb>What do you mean by validate?
When we migrated from SVN to Git, Infra completely ignored tags in the Git
repository.
They did not care
sebb>That was certainly how I read the Infra email.
So is rel/v5.2.0 tag enough in your opinion?
Vladimir
On Tue, 1 Oct 2019 at 14:59, Vladimir Sitnikov
wrote:
>
> >part of the release process
> >should become tagging the voted upon commit SHA under rel/ to make it
> >indelible. ('# git tag rel/v15.4.2 ' or something similar.)
>
> We have "publishRelase" Gradle task that creates "release tag" and move
>part of the release process
>should become tagging the voted upon commit SHA under rel/ to make it
>indelible. ('# git tag rel/v15.4.2 ' or something similar.)
We have "publishRelase" Gradle task that creates "release tag" and moves
the release from dev to release area on dist.apahce.org.
We coul
12 matches
Mail list logo
