Removing branch_5x shortly

classic Classic list List threaded Threaded
35 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Removing branch_5x shortly

Michael McCandless-2
Please don't back-port anything to branch_5x: I'd like to remove it,
i.e. any back-ports from master should be only bug fixes and go to
branch_5_5's next bug fix release (5.5.1) instead.

I see some recent commits for Solr here ... if these are really
bug-fixes, please re-push to 5.5 branch instead.

The current tip of branch_5x is
e8acc04c68ac74ca5757285581c42457100c990c ... I don't fully understand
how git will GC this once I remove branch_5x.

Mike McCandless

http://blog.mikemccandless.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Removing branch_5x shortly

Dawid Weiss-2


Before you do push anything can you explain or give the commands you plan to execute Mike? Deleting a branch is typically not a good idea that's why I ask.

On Feb 20, 2016 17:52, "Michael McCandless" <[hidden email]> wrote:
Please don't back-port anything to branch_5x: I'd like to remove it,
i.e. any back-ports from master should be only bug fixes and go to
branch_5_5's next bug fix release (5.5.1) instead.

I see some recent commits for Solr here ... if these are really
bug-fixes, please re-push to 5.5 branch instead.

The current tip of branch_5x is
e8acc04c68ac74ca5757285581c42457100c990c ... I don't fully understand
how git will GC this once I remove branch_5x.

Mike McCandless

http://blog.mikemccandless.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Removing branch_5x shortly

Michael McCandless-2
Thanks for asking :)

I was just going to do:

  git push origin --delete branch_5x

(Instead of the crazy all-powerful-colon syntax).

This just removes the "pointer" (branch_5x) to the latest commit hash
right?  The commits unique to that branch still remain unless we ask
git to reclaim them?  Or does git reclaim un-referenced nodes on its
own sometimes...?

Mike McCandless

http://blog.mikemccandless.com


On Sat, Feb 20, 2016 at 12:17 PM, Dawid Weiss <[hidden email]> wrote:

>
> Before you do push anything can you explain or give the commands you plan to
> execute Mike? Deleting a branch is typically not a good idea that's why I
> ask.
>
> On Feb 20, 2016 17:52, "Michael McCandless" <[hidden email]>
> wrote:
>>
>> Please don't back-port anything to branch_5x: I'd like to remove it,
>> i.e. any back-ports from master should be only bug fixes and go to
>> branch_5_5's next bug fix release (5.5.1) instead.
>>
>> I see some recent commits for Solr here ... if these are really
>> bug-fixes, please re-push to 5.5 branch instead.
>>
>> The current tip of branch_5x is
>> e8acc04c68ac74ca5757285581c42457100c990c ... I don't fully understand
>> how git will GC this once I remove branch_5x.
>>
>> Mike McCandless
>>
>> http://blog.mikemccandless.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Removing branch_5x shortly

Yonik Seeley
In reply to this post by Michael McCandless-2
Why are we precluding a future 5.6 release (or are we)?

-Yonik

On Sat, Feb 20, 2016 at 11:52 AM, Michael McCandless
<[hidden email]> wrote:

> Please don't back-port anything to branch_5x: I'd like to remove it,
> i.e. any back-ports from master should be only bug fixes and go to
> branch_5_5's next bug fix release (5.5.1) instead.
>
> I see some recent commits for Solr here ... if these are really
> bug-fixes, please re-push to 5.5 branch instead.
>
> The current tip of branch_5x is
> e8acc04c68ac74ca5757285581c42457100c990c ... I don't fully understand
> how git will GC this once I remove branch_5x.
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Removing branch_5x shortly

Michael McCandless-2
We are precluding it: 5.5.x is the last feature release before 6.0.0.

I don't think we should do another 5.x feature release after 6.0.0 is out.

Mike McCandless

http://blog.mikemccandless.com

On Sat, Feb 20, 2016 at 12:30 PM, Yonik Seeley <[hidden email]> wrote:

> Why are we precluding a future 5.6 release (or are we)?
>
> -Yonik
>
> On Sat, Feb 20, 2016 at 11:52 AM, Michael McCandless
> <[hidden email]> wrote:
>> Please don't back-port anything to branch_5x: I'd like to remove it,
>> i.e. any back-ports from master should be only bug fixes and go to
>> branch_5_5's next bug fix release (5.5.1) instead.
>>
>> I see some recent commits for Solr here ... if these are really
>> bug-fixes, please re-push to 5.5 branch instead.
>>
>> The current tip of branch_5x is
>> e8acc04c68ac74ca5757285581c42457100c990c ... I don't fully understand
>> how git will GC this once I remove branch_5x.
>>
>> Mike McCandless
>>
>> http://blog.mikemccandless.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Removing branch_5x shortly

Yonik Seeley
On Sat, Feb 20, 2016 at 12:46 PM, Michael McCandless
<[hidden email]> wrote:
> We are precluding it: 5.5.x is the last feature release before 6.0.0.
>
> I don't think we should do another 5.x feature release after 6.0.0 is out.

Can't that be decided at some point in the future (i.e. if someone
wants to go through the work of backporting some features to 5x and
making a 5.6)?
Or is there a technical reason (like something to do with the versions
stored in the index) why that wouldn't be feasible?

-Yonik

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Removing branch_5x shortly

Dawid Weiss-2
In reply to this post by Michael McCandless-2
>   git push origin --delete branch_5x
>
> (Instead of the crazy all-powerful-colon syntax).

Ok. I don't think it's the right way to do it.

> This just removes the "pointer" (branch_5x) to the latest commit hash
> right?  The commits unique to that branch still remain unless we ask
> git to reclaim them?  Or does git reclaim un-referenced nodes on its
> own sometimes...?

This means you need to re-read my git tutorials :) Or perhaps I should
add one specific to deleting a (remote) reference...

In short: git gc is much like Java's gc. Think of git commits as Java
objects -- if they are not referenced from any "gc roots" they are
eligible for permanent deletion. Git's "gc roots" are essentially
those commits which are pointed to by any reference (tag, branch...
anything you see when you issue "git show-ref"). Git's equivalent of
Java's "references" are "parent" commits from a commit (a single
commit can have one parent -> linear history or multiple parents -> a
merge). There is also a "temporary backlog" of recent operations
called a "reflog" which points to all commits involved in recent local
commands... but when this expires the commits will be eventually
dropped.

Anything not "reachable" from gc roots or the reflog is eligible for
permanent deletion. So any commits not reachable from a tag or other
branch would be forgotten after you delete branch_5x.

There's also another aspect of deleting a remote branch -- this
deletion isn't automatically "propagated" to any other forks (so other
committers would still see a remote branch_5x). You'd have to ask
everyone to prune remote references.

For these reasons I think we should just leave branch_5x as is. If you
really want to enforce no further commits on it I'd delete all the
files from that branch and leave a README file saying this branch is
effectively dead.

Dawid

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Removing branch_5x shortly

Mark Miller-3
Can't we tag it and then delete the branch?

I'm not a fan of removal as a way to prevent commits though. We should see if infra let's us put in any git hooks and protect branches from there.

I'm not convinced we need a new strategy just because we are on git though. We generally don't decide we won't do a release, someone volunteers to put one together when something prompts it. I don't remember protecting branches in SVN and so I wonder if we need to now?

- Mark

On Sat, Feb 20, 2016 at 1:37 PM Dawid Weiss <[hidden email]> wrote:
>   git push origin --delete branch_5x
>
> (Instead of the crazy all-powerful-colon syntax).

Ok. I don't think it's the right way to do it.

> This just removes the "pointer" (branch_5x) to the latest commit hash
> right?  The commits unique to that branch still remain unless we ask
> git to reclaim them?  Or does git reclaim un-referenced nodes on its
> own sometimes...?

This means you need to re-read my git tutorials :) Or perhaps I should
add one specific to deleting a (remote) reference...

In short: git gc is much like Java's gc. Think of git commits as Java
objects -- if they are not referenced from any "gc roots" they are
eligible for permanent deletion. Git's "gc roots" are essentially
those commits which are pointed to by any reference (tag, branch...
anything you see when you issue "git show-ref"). Git's equivalent of
Java's "references" are "parent" commits from a commit (a single
commit can have one parent -> linear history or multiple parents -> a
merge). There is also a "temporary backlog" of recent operations
called a "reflog" which points to all commits involved in recent local
commands... but when this expires the commits will be eventually
dropped.

Anything not "reachable" from gc roots or the reflog is eligible for
permanent deletion. So any commits not reachable from a tag or other
branch would be forgotten after you delete branch_5x.

There's also another aspect of deleting a remote branch -- this
deletion isn't automatically "propagated" to any other forks (so other
committers would still see a remote branch_5x). You'd have to ask
everyone to prune remote references.

For these reasons I think we should just leave branch_5x as is. If you
really want to enforce no further commits on it I'd delete all the
files from that branch and leave a README file saying this branch is
effectively dead.

Dawid

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

--
Reply | Threaded
Open this post in threaded view
|

Re: Removing branch_5x shortly

Dawid Weiss-2
> Can't we tag it and then delete the branch?

Any reference. So yes, sure you can. But this doesn't really address
the second part of my e-mail -- people would still have to issue:

git remote prune origin

and I don't want to fight Uwe over supposedly magical git commands :)

> if infra let's us put in any git hooks and protect branches from there.

Yes, this would be another option (but it requires admin-side tweaks).

> I'm not convinced we need a new strategy just because we are on git though.
> We generally don't decide we won't do a release, someone volunteers to put
> one together when something prompts it. I don't remember protecting branches
> in SVN and so I wonder if we need to now?

Exactly. We really don't need to do anything other than just agree to
not commit there... that's part of the reason I wanted more "semantic"
names for branches -- they're kind of hard to eradicate once created
in public.

Anyway, as for branch_5x -- no need to protect anything, really. If
somebody DOES commit something (by accident or otherwise) we can
always revert those commits (or even force the reference to what it
was before the mistake, effectively undoing the change).

D.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Removing branch_5x shortly

Uwe Schindler
Hi,

Let's keep the branch. The other ones from 3 and 4 are also still there.

If anybody commits, who cares? If we don't release, it's just useless work.

If we want to nuke branch, do the same for previous ones.

Uwe

Am 20. Februar 2016 19:58:21 MEZ, schrieb Dawid Weiss <[hidden email]>:
Can't we tag it and then delete the branch?

Any reference. So yes, sure you can. But this doesn't really address
the second part of my e-mail -- people would still have to issue:

git remote prune origin

and I don't want to fight Uwe over supposedly magical git commands :)

if infra let's us put in any git hooks and protect branches from there.

Yes, this would be another option (but it requires admin-side tweaks).

I'm not convinced we need a new strategy just because we are on git though.
We generally don't decide we won't do a release, someone volunteers to put
one together when something prompts it. I don't remember protecting branches
in SVN and so I wonder if we need to now?

Exactly. We really don't need to do anything other than just agree to
not commit there... that's part of the reason I wanted more "semantic"
names for branches -- they're kind of hard to eradicate once created
in public.

Anyway, as for branch_5x -- no need to protect anything, really. If
somebody DOES commit something (by accident or otherwise) we can
always revert those commits (or even force the reference to what it
was before the mistake, effectively undoing the change).

D.



To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


--
Uwe Schindler
H.-H.-Meier-Allee 63, 28213 Bremen
http://www.thetaphi.de
Reply | Threaded
Open this post in threaded view
|

Re: Removing branch_5x shortly

Jack Krupansky-3
+1 for managing git branches the same way as branches were managed in svn (modulo any specific technical differences of git vs. svn). I see only branch_5x in svn right now - when in the staging of release 5.0 was branch_4x deleted?

Looking at the official ReleaseToDo wiki, I don't actually see any process for removing old branches. So what exactly wss the old informal guidance that determined when branch_4x was removed>?

BTW, when branchng for a new release, I see this confusing statement: "For the first release in a minor release series - i.e. X.Y.0 - create a minor release branch off the current major version branch, e.g. for minor release 5.5." I mean, shouldn't there be two separate statements, first the creation of the stable branch on a major release, and second the creation of a point/bugfix branch from the stable branch on a minor release? Or have explicit sections for "Major release", "Minor release", and "Bugfix release".

-- Jack Krupansky

On Sat, Feb 20, 2016 at 2:26 PM, Uwe Schindler <[hidden email]> wrote:
Hi,

Let's keep the branch. The other ones from 3 and 4 are also still there.

If anybody commits, who cares? If we don't release, it's just useless work.

If we want to nuke branch, do the same for previous ones.

Uwe

Am 20. Februar 2016 19:58:21 MEZ, schrieb Dawid Weiss <[hidden email]>:
Can't we tag it and then delete the branch?

Any reference. So yes, sure you can. But this doesn't really address
the second part of my e-mail -- people would still have to issue:

git remote prune origin

and I don't want to fight Uwe over supposedly magical git commands :)

if infra let's us put in any git hooks and protect branches from there.

Yes, this would be another option (but it requires admin-side tweaks).

I'm not convinced we need a new strategy just because we are on git though.
We generally don't decide we won't do a release, someone volunteers to put
one together when something prompts it. I don't remember protecting branches
in SVN and so I wonder if we need to now?

Exactly. We really don't need to do anything other than just agree to
not commit there... that's part of the reason I wanted more "semantic"
names for branches -- they're kind of hard to eradicate once created
in public.

Anyway, as for branch_5x -- no need to protect anything, really. If
somebody DOES commit something (by accident or otherwise) we can
always revert those commits (or even force the reference to what it
was before the mistake, effectively undoing the change).

D.



To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


--
Uwe Schindler
H.-H.-Meier-Allee 63, 28213 Bremen
http://www.thetaphi.de

Reply | Threaded
Open this post in threaded view
|

Re: Removing branch_5x shortly

Mark Miller-3
bq. So what exactly was the old informal guidance that determined when branch_4x was removed>?

Interesting, you are right. I don't recall that at all. There is probably a JIRA or email thread needle out there with the discussion. Silence and absence is consensus. I may even have been for the idea at the time, no recollection. I assume we made some decision at some point to clean out all the old branches.

If we did not have the technical issues Dawid is concerned about, I would say, removing really old dead dev branches doesn't bother me much. But it seems we should always at least keep the last branch.

But then removing it doesn't seem to make much sense with Git anyway. And it's not like we release so fast that the number of branches is overwhelming.

- Mark

On Sat, Feb 20, 2016 at 3:08 PM Jack Krupansky <[hidden email]> wrote:
+1 for managing git branches the same way as branches were managed in svn (modulo any specific technical differences of git vs. svn). I see only branch_5x in svn right now - when in the staging of release 5.0 was branch_4x deleted?

Looking at the official ReleaseToDo wiki, I don't actually see any process for removing old branches. So what exactly wss the old informal guidance that determined when branch_4x was removed>?

BTW, when branchng for a new release, I see this confusing statement: "For the first release in a minor release series - i.e. X.Y.0 - create a minor release branch off the current major version branch, e.g. for minor release 5.5." I mean, shouldn't there be two separate statements, first the creation of the stable branch on a major release, and second the creation of a point/bugfix branch from the stable branch on a minor release? Or have explicit sections for "Major release", "Minor release", and "Bugfix release".

-- Jack Krupansky

On Sat, Feb 20, 2016 at 2:26 PM, Uwe Schindler <[hidden email]> wrote:
Hi,

Let's keep the branch. The other ones from 3 and 4 are also still there.

If anybody commits, who cares? If we don't release, it's just useless work.

If we want to nuke branch, do the same for previous ones.

Uwe

Am 20. Februar 2016 19:58:21 MEZ, schrieb Dawid Weiss <[hidden email]>:
Can't we tag it and then delete the branch?

Any reference. So yes, sure you can. But this doesn't really address
the second part of my e-mail -- people would still have to issue:

git remote prune origin

and I don't want to fight Uwe over supposedly magical git commands :)

if infra let's us put in any git hooks and protect branches from there.

Yes, this would be another option (but it requires admin-side tweaks).

I'm not convinced we need a new strategy just because we are on git though.
We generally don't decide we won't do a release, someone volunteers to put
one together when something prompts it. I don't remember protecting branches
in SVN and so I wonder if we need to now?

Exactly. We really don't need to do anything other than just agree to
not commit there... that's part of the reason I wanted more "semantic"
names for branches -- they're kind of hard to eradicate once created
in public.

Anyway, as for branch_5x -- no need to protect anything, really. If
somebody DOES commit something (by accident or otherwise) we can
always revert those commits (or even force the reference to what it
was before the mistake, effectively undoing the change).

D.



To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


--
Uwe Schindler
H.-H.-Meier-Allee 63, 28213 Bremen
http://www.thetaphi.de

--
Reply | Threaded
Open this post in threaded view
|

Re: Removing branch_5x shortly

Michael McCandless-2
In reply to this post by Uwe Schindler
I was simply going by what we did when we released 5.0, which was to
remove the 4.x branch (or rename it to 4.10.x maybe, but the net
effect is the same).  I thought this was the practice for a major
release.

But it sounds like removing this branch in git is ... not a good idea
technically.

And even if it were technically possible (having everyone run "git
remote prune origin"), clearly everyone here disagrees we should do
so.

So I'll leave it be.

Thanks for the git explanation Dawid!  It sounds like one must assume
git's gc is immediate, i.e. upon removing the branch, any commits not
reachable by any other "roots" would be deleted, even if you
"remembered" their specific commit hashes yourself.

Mike McCandless

http://blog.mikemccandless.com

On Sat, Feb 20, 2016 at 2:26 PM, Uwe Schindler <[hidden email]> wrote:

> Hi,
>
> Let's keep the branch. The other ones from 3 and 4 are also still there.
>
> If anybody commits, who cares? If we don't release, it's just useless work.
>
> If we want to nuke branch, do the same for previous ones.
>
> Uwe
>
> Am 20. Februar 2016 19:58:21 MEZ, schrieb Dawid Weiss
> <[hidden email]>:
>>>
>>>  Can't we tag it and then delete the branch?
>>
>>
>> Any reference. So yes, sure you can. But this doesn't really address
>> the second part of my e-mail -- people would still have to issue:
>>
>> git remote prune origin
>>
>> and I don't want to fight Uwe over supposedly magical git commands :)
>>
>>>  if infra let's us put in any git hooks and protect branches from there.
>>
>>
>> Yes, this would be another option (but it requires admin-side tweaks).
>>
>>>  I'm not convinced we need a new strategy just because we are on git
>>> though.
>>>  We generally don't decide
>>> we won't do a release, someone volunteers to put
>>>  one together when something prompts it. I don't remember protecting
>>> branches
>>>  in SVN and so I wonder if we need to now?
>>
>>
>> Exactly. We really don't need to do anything other than just agree to
>> not commit there... that's part of the reason I wanted more "semantic"
>> names for branches -- they're kind of hard to eradicate once created
>> in public.
>>
>> Anyway, as for branch_5x -- no need to protect anything, really. If
>> somebody DOES commit something (by accident or otherwise) we can
>> always revert those commits (or even force the reference to what it
>> was before the mistake, effectively undoing the change).
>>
>> D.
>>
>> ________________________________
>>
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
> --
> Uwe Schindler
> H.-H.-Meier-Allee 63, 28213 Bremen
> http://www.thetaphi.de

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Removing branch_5x shortly

Yonik Seeley
On Sat, Feb 20, 2016 at 3:33 PM, Michael McCandless
<[hidden email]> wrote:
> I was simply going by what we did when we released 5.0, which was to
> remove the 4.x branch (or rename it to 4.10.x maybe, but the net
> effect is the same).  I thought this was the practice for a major
> release.

That was a one-off that caught a lot of people by surprise.  It had
not been done on previous major releases.
There was already even a lot of work toward 4.11 when the deletion
happened IIRC.

-Yonik

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Removing branch_5x shortly

Michael McCandless-2
In reply to this post by Yonik Seeley
On Sat, Feb 20, 2016 at 1:32 PM, Yonik Seeley <[hidden email]> wrote:

> On Sat, Feb 20, 2016 at 12:46 PM, Michael McCandless
> <[hidden email]> wrote:
>> We are precluding it: 5.5.x is the last feature release before 6.0.0.
>>
>> I don't think we should do another 5.x feature release after 6.0.0 is out.
>
> Can't that be decided at some point in the future (i.e. if someone
> wants to go through the work of backporting some features to 5x and
> making a 5.6)?
> Or is there a technical reason (like something to do with the versions
> stored in the index) why that wouldn't be feasible?

That's exactly it.

In a 5.6 release we are normally free to improve the index format, as
long as the change is backwards compatible (5.6 can still read all 4.x
and 5.x indices).

But if we do that then the (already released) 6.0 won't be able to
read 5.6 indices, which I think would be very bad.

Mike McCandless

http://blog.mikemccandless.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Removing branch_5x shortly

Yonik Seeley
On Sat, Feb 20, 2016 at 3:42 PM, Michael McCandless
<[hidden email]> wrote:
> But if we do that then the (already released) 6.0 won't be able to
> read 5.6 indices, which I think would be very bad.

For sure, forward compatibility would need to apply.
That still leaves open a wide range of features at both the Lucene and
Solr level though.  If someone wanted to release a 5.6 that wasn't
forward compatible (to the degree that 5.5 will be) that would be a
reason to vote against it.

If, on the other hand, a future 5.6 would not be forward compatible by
the mere fact that it's called "5.6" then that should be fixed now,
before 6.0 is released.  We shouldn't be forced to preclude additional
5.x releases.

-Yonik

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Removing branch_5x shortly

Anshum Gupta
In reply to this post by Yonik Seeley
Here's a similar question that came up during the 5.0 release.

The reply to this was convincing back then as 5.0 was released for different reasons, and in different circumstances. It certainly wasn't the norm.

Unless I'm missing something here, I don't see a reason to not keep 5x and even potentially release 5.6 at some point as long as some one has a reason and the time to work on a 5.6 release.

Also, as Uwe said, it might be wasted effort committing to the 5x branch but that wouldn't hurt us.


On Sat, Feb 20, 2016 at 12:41 PM, Yonik Seeley <[hidden email]> wrote:
On Sat, Feb 20, 2016 at 3:33 PM, Michael McCandless
<[hidden email]> wrote:
> I was simply going by what we did when we released 5.0, which was to
> remove the 4.x branch (or rename it to 4.10.x maybe, but the net
> effect is the same).  I thought this was the practice for a major
> release.

That was a one-off that caught a lot of people by surprise.  It had
not been done on previous major releases.
There was already even a lot of work toward 4.11 when the deletion
happened IIRC.

-Yonik

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]




--
Anshum Gupta
Reply | Threaded
Open this post in threaded view
|

Re: Removing branch_5x shortly

Mark Miller-3
In reply to this post by Michael McCandless-2
I think it fits a lot more with how we work to add some documentation to the release wiki and or elsewhere about changing index format after the next major release, and that the release manager should ping the list and scan changes for potential violations in such release situations.

That seems much more in line with our practices and let's us keep the stable line alive. If we cannot do that, all this crazy effort we put into two simultaneous branches has even less value.

- Mark

On Sat, Feb 20, 2016 at 3:47 PM Michael McCandless <[hidden email]> wrote:
On Sat, Feb 20, 2016 at 1:32 PM, Yonik Seeley <[hidden email]> wrote:
> On Sat, Feb 20, 2016 at 12:46 PM, Michael McCandless
> <[hidden email]> wrote:
>> We are precluding it: 5.5.x is the last feature release before 6.0.0.
>>
>> I don't think we should do another 5.x feature release after 6.0.0 is out.
>
> Can't that be decided at some point in the future (i.e. if someone
> wants to go through the work of backporting some features to 5x and
> making a 5.6)?
> Or is there a technical reason (like something to do with the versions
> stored in the index) why that wouldn't be feasible?

That's exactly it.

In a 5.6 release we are normally free to improve the index format, as
long as the change is backwards compatible (5.6 can still read all 4.x
and 5.x indices).

But if we do that then the (already released) 6.0 won't be able to
read 5.6 indices, which I think would be very bad.

Mike McCandless

http://blog.mikemccandless.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

--
Reply | Threaded
Open this post in threaded view
|

Re: Removing branch_5x shortly

Mark Miller-3
In reply to this post by Anshum Gupta
Not the norm is an understatement reading that issue :) 

- Mark

On Sat, Feb 20, 2016 at 4:04 PM Anshum Gupta <[hidden email]> wrote:
Here's a similar question that came up during the 5.0 release.

The reply to this was convincing back then as 5.0 was released for different reasons, and in different circumstances. It certainly wasn't the norm.

Unless I'm missing something here, I don't see a reason to not keep 5x and even potentially release 5.6 at some point as long as some one has a reason and the time to work on a 5.6 release.

Also, as Uwe said, it might be wasted effort committing to the 5x branch but that wouldn't hurt us.


On Sat, Feb 20, 2016 at 12:41 PM, Yonik Seeley <[hidden email]> wrote:
On Sat, Feb 20, 2016 at 3:33 PM, Michael McCandless
<[hidden email]> wrote:
> I was simply going by what we did when we released 5.0, which was to
> remove the 4.x branch (or rename it to 4.10.x maybe, but the net
> effect is the same).  I thought this was the practice for a major
> release.

That was a one-off that caught a lot of people by surprise.  It had
not been done on previous major releases.
There was already even a lot of work toward 4.11 when the deletion
happened IIRC.

-Yonik

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]




--
Anshum Gupta
--
Reply | Threaded
Open this post in threaded view
|

Re: Removing branch_5x shortly

Dawid Weiss-2
In reply to this post by Michael McCandless-2
> It sounds like one must assume git's gc is immediate, i.e. upon removing the branch, any commits not reachable by any other "roots" would be deleted, even if you "remembered" their specific commit hashes yourself.

No, it isn't immediate. git tries hard to preserve your work in case
you screw up. If you do want to "System.gc()" you need to do this as a
two-step process in git -- expunge the reflog and then rewrite
commits. It is *very* unusual that you'd really want to do it (much
like trying to "brute-force" a GC in Java).

Dawid


On Sat, Feb 20, 2016 at 9:33 PM, Michael McCandless
<[hidden email]> wrote:

> I was simply going by what we did when we released 5.0, which was to
> remove the 4.x branch (or rename it to 4.10.x maybe, but the net
> effect is the same).  I thought this was the practice for a major
> release.
>
> But it sounds like removing this branch in git is ... not a good idea
> technically.
>
> And even if it were technically possible (having everyone run "git
> remote prune origin"), clearly everyone here disagrees we should do
> so.
>
> So I'll leave it be.
>
> Thanks for the git explanation Dawid!  It sounds like one must assume
> git's gc is immediate, i.e. upon removing the branch, any commits not
> reachable by any other "roots" would be deleted, even if you
> "remembered" their specific commit hashes yourself.
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
> On Sat, Feb 20, 2016 at 2:26 PM, Uwe Schindler <[hidden email]> wrote:
>> Hi,
>>
>> Let's keep the branch. The other ones from 3 and 4 are also still there.
>>
>> If anybody commits, who cares? If we don't release, it's just useless work.
>>
>> If we want to nuke branch, do the same for previous ones.
>>
>> Uwe
>>
>> Am 20. Februar 2016 19:58:21 MEZ, schrieb Dawid Weiss
>> <[hidden email]>:
>>>>
>>>>  Can't we tag it and then delete the branch?
>>>
>>>
>>> Any reference. So yes, sure you can. But this doesn't really address
>>> the second part of my e-mail -- people would still have to issue:
>>>
>>> git remote prune origin
>>>
>>> and I don't want to fight Uwe over supposedly magical git commands :)
>>>
>>>>  if infra let's us put in any git hooks and protect branches from there.
>>>
>>>
>>> Yes, this would be another option (but it requires admin-side tweaks).
>>>
>>>>  I'm not convinced we need a new strategy just because we are on git
>>>> though.
>>>>  We generally don't decide
>>>> we won't do a release, someone volunteers to put
>>>>  one together when something prompts it. I don't remember protecting
>>>> branches
>>>>  in SVN and so I wonder if we need to now?
>>>
>>>
>>> Exactly. We really don't need to do anything other than just agree to
>>> not commit there... that's part of the reason I wanted more "semantic"
>>> names for branches -- they're kind of hard to eradicate once created
>>> in public.
>>>
>>> Anyway, as for branch_5x -- no need to protect anything, really. If
>>> somebody DOES commit something (by accident or otherwise) we can
>>> always revert those commits (or even force the reference to what it
>>> was before the mistake, effectively undoing the change).
>>>
>>> D.
>>>
>>> ________________________________
>>>
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>
>> --
>> Uwe Schindler
>> H.-H.-Meier-Allee 63, 28213 Bremen
>> http://www.thetaphi.de
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

12