Mailing List Archive

On 2013-04-08, at 8:55 AM, David E. Wheeler <david@justatheory.com> wrote:

> Fellow Bricoleurs,
>
> So I just noticed that there are a bunch of pending 2.0.2 changes, as well as a few enhancements for 2.2.0. Who wants to do a 2.0.2 release and a 2.1.0 (rc for 2.2.0)? Long overdue.

Fingers crossed that our faithful Bret Dawson is still in shape to roll releases.

--
Phillip Smith
http://phillipadsmith.com
http://twitter.com/phillipadsmith
http://linkedin.com/in/phillipadsmith

If your email inbox is out of control, check out http://sanebox.com/t/s0q7m

Save our in-boxes! http://emailcharter.org

OK, I'll do it. Sometime in the next week and a half, I expect.


Later,

Bret


--
Bret Dawson
Producer
Pectopah Productions Inc.
(416) 895-7635
bret@pectopah.com
www.pectopah.com


On Mon, 2013-04-08 at 08:55 -0700, David E.Wheeler wrote:
> Fellow Bricoleurs,
>
> So I just noticed that there are a bunch of pending 2.0.2 changes, as well as a few enhancements for 2.2.0. Who wants to do a 2.0.2 release and a 2.1.0 (rc for 2.2.0)? Long overdue.
>
> Best,
>
> David

I've got a bit of time now, and I'm willing to take a run at releases 2.0.2 if no one else is going to jump on it.

David: when are you around/available should I hit a bump?

Phillip.

On 2013-04-08, at 4:05 PM, Phillip Smith <ps@phillipadsmith.com> wrote:

>
> On 2013-04-08, at 8:55 AM, David E. Wheeler <david@justatheory.com> wrote:
>
>> Fellow Bricoleurs,
>>
>> So I just noticed that there are a bunch of pending 2.0.2 changes, as well as a few enhancements for 2.2.0. Who wants to do a 2.0.2 release and a 2.1.0 (rc for 2.2.0)? Long overdue.
>
> Fingers crossed that our faithful Bret Dawson is still in shape to roll releases.
>
> --
> Phillip Smith
> http://phillipadsmith.com
> http://twitter.com/phillipadsmith
> http://linkedin.com/in/phillipadsmith
>
> If your email inbox is out of control, check out http://sanebox.com/t/s0q7m
>
> Save our in-boxes! http://emailcharter.org
>

--
Phillip Smith
http://phillipadsmith.com

On Oct 6, 2013, at 2:12 PM, Phillip Smith <ps@phillipadsmith.com> wrote:

> I've got a bit of time now, and I'm willing to take a run at releases 2.0.2 if no one else is going to jump on it.
>
> David: when are you around/available should I hit a bump?

I'm on IRC regular work hours.

D

On 2013-10-07, at 1:27 PM, David E. Wheeler <david@kineticode.com> wrote:

> On Oct 6, 2013, at 2:12 PM, Phillip Smith <ps@phillipadsmith.com> wrote:
>
>> I've got a bit of time now, and I'm willing to take a run at releases 2.0.2 if no one else is going to jump on it.
>>
>> David: when are you around/available should I hit a bump?
>
> I'm on IRC regular work hours.

I've got a version of bricoleurs/bricolage master branch with the most recent pull requested merged (and re-tested). I've updated Bric::Changes (just with a few lines for the most recent bug fixes), and I've incremented inst/versions.txt from 2.1.0 to 2.2.0 … though, looking through Bric::Changes and so on, I can't make out if this should be 2.2.0 or 2.0.2.

Reading the last comment here:
https://github.com/bricoleurs/bricolage/pull/49#issuecomment-36291906

It leads me to believe that I should:

a) Push these local changes to bricolage/tree/master

b) Merge these changes into bricolage/tree/rev-2.0

However, rev-2.0 says "This branch is 118 commits ahead and 149 commits behind master" -- which is quite confusing to say the least. If I try a basic --no-ff merge, I see a lot of merge conflicts (that I'd rather not have to work through by hand if possible).

Any pointers appreciated.

Phillip.

--
Phillip Smith
http://phillipadsmith.com

On Jul 14, 2014, at 8:00 PM, Phillip Smith <ps@phillipadsmith.com> wrote:

> I've got a version of bricoleurs/bricolage master branch with the most recent pull requested merged (and re-tested). I've updated Bric::Changes (just with a few lines for the most recent bug fixes), and I've incremented inst/versions.txt from 2.1.0 to 2.2.0 … though, looking through Bric::Changes and so on, I can't make out if this should be 2.2.0 or 2.0.2.
>
> Reading the last comment here:
> https://github.com/bricoleurs/bricolage/pull/49#issuecomment-36291906
>
> It leads me to believe that I should:
>
> a) Push these local changes to bricolage/tree/master
>
> b) Merge these changes into bricolage/tree/rev-2.0

Yeah, that will work. Make sure the changes are listed for the 2.0.1 section of the changes file, unless you plan to release 2.2.0. Which maybe you could, and just ignore the 2.0 branch from here on in.

> However, rev-2.0 says "This branch is 118 commits ahead and 149 commits behind master" -- which is quite confusing to say the least. If I try a basic --no-ff merge, I see a lot of merge conflicts (that I'd rather not have to work through by hand if possible).

Your rev-2.0 branch is likely fucked up. You should kill it and create a new one from upstream.

git checkout master
git branch -d rev-2.0
git checkout -d rev-2.0 upstream/rev-2.0
git push origin -u rev-2.0 --force

Best,

David

On 2014-07-14, at 11:54 PM, "David E. Wheeler" <david@justatheory.com> wrote:

>
> On Jul 14, 2014, at 8:00 PM, Phillip Smith <ps@phillipadsmith.com> wrote:
>
>> I've got a version of bricoleurs/bricolage master branch with the most recent pull requested merged (and re-tested). I've updated Bric::Changes (just with a few lines for the most recent bug fixes), and I've incremented inst/versions.txt from 2.1.0 to 2.2.0 … though, looking through Bric::Changes and so on, I can't make out if this should be 2.2.0 or 2.0.2.
>>
>> Reading the last comment here:
>> https://github.com/bricoleurs/bricolage/pull/49#issuecomment-36291906
>>
>> It leads me to believe that I should:
>>
>> a) Push these local changes to bricolage/tree/master
>>
>> b) Merge these changes into bricolage/tree/rev-2.0
>
> Yeah, that will work. Make sure the changes are listed for the 2.0.1 section of the changes file, unless you plan to release 2.2.0. Which maybe you could, and just ignore the 2.0 branch from here on in.

Still unclear on the "right(™)" direction here? Should I release 2.0.1 or 2.2.0 or both… or? Sorry for being dense here; just want to stay with whatever strategy has been used in the past (or that will be easiest in the future).


>> However, rev-2.0 says "This branch is 118 commits ahead and 149 commits behind master" -- which is quite confusing to say the least. If I try a basic --no-ff merge, I see a lot of merge conflicts (that I'd rather not have to work through by hand if possible).
>
> Your rev-2.0 branch is likely fucked up. You should kill it and create a new one from upstream.

That's not on MY BRANCH, that's on YOUR BRANCH! :-P (See screenshot here: http://note.io/1reioob )

--
Phillip Smith
http://phillipadsmith.com

On Jul 15, 2014, at 11:08 AM, Phillip Smith <ps@phillipadsmith.com> wrote:

> Still unclear on the "right(™)" direction here? Should I release 2.0.1 or 2.2.0 or both… or? Sorry for being dense here; just want to stay with whatever strategy has been used in the past (or that will be easiest in the future).

Since it has been so long, I say screw 2.1.0 and release 2.2.0. Then just maintain that going forward, with no maintenance of older versions. Just one line to maintain. We do releases so rarely, and with so little changed, that I see no advantage to it anymore.

So get the master branch straightened out, make sure all changes from the rel-2.0 branch are merged, move the changes listed for 2.1.0 to 2.2.0, then release 2.2.0.
>
> That's not on MY BRANCH, that's on YOUR BRANCH! :-P (See screenshot here: http://note.io/1reioob )

Oh, don’t worry about that, we maintained rel-2.0 separate from Master, so we never merged it.

Best,

David