You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pdfbox.apache.org by Andreas Lehmkuehler <an...@lehmi.de> on 2017/03/21 16:53:58 UTC

Branch for new major version?

Hi,

I'm thinking about implementing some stuff which would most likely require a new 
major version. Obviously there are some similar things which already came up, 
e.g. remove some disturbing public constants, switch to java 7 to use twelve 
monkeys lib.

The question is, how should we deal with that. I see a handful of possible ways:

- switch the current trunk to 3.0 and omit 2.1 (for now there are 3 tickets with 
"Fix version/s" 2.1 which didn't make it to the 2.0 branch for different reasons)
- create a 2.1 branch based on the current trunk and switch the current trunk to 3.0
- create a 3.0 branch and don't change anything else. Merge all changes to the 
trunk once 2.1 was released some time in the future
- don't change anything officially, but create a "private" 3.0 branch and merge 
those changes to a future 3.0 version

What is your opinion? Any other ideas?
BTW: I'd prefer 1 or 2

BR
Andreas

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: dev-help@pdfbox.apache.org

Re: Branch for new major version?

Posted by Andreas Lehmkuehler <an...@lehmi.de>.
Am 25.03.2017 um 19:01 schrieb Andreas Lehmkuehler:
> Am 23.03.2017 um 07:50 schrieb Andreas Lehmkuehler:
>> Am 21.03.2017 um 19:45 schrieb Maruan Sahyoun:
>>>
>>>> Am 21.03.2017 um 19:17 schrieb Tilman Hausherr <TH...@t-online.de>:
>>>>
>>>> Am 21.03.2017 um 17:53 schrieb Andreas Lehmkuehler:
>>>>> Hi,
>>>>>
>>>>> I'm thinking about implementing some stuff which would most likely require a
>>>>> new major version. Obviously there are some similar things which already
>>>>> came up, e.g. remove some disturbing public constants, switch to java 7 to
>>>>> use twelve monkeys lib.
>>>>>
>>>>> The question is, how should we deal with that. I see a handful of possible
>>>>> ways:
>>>>>
>>>>> - switch the current trunk to 3.0 and omit 2.1 (for now there are 3 tickets
>>>>> with "Fix version/s" 2.1 which didn't make it to the 2.0 branch for
>>>>> different reasons)
>>>>> - create a 2.1 branch based on the current trunk and switch the current
>>>>> trunk to 3.0
>>>>> - create a 3.0 branch and don't change anything else. Merge all changes to
>>>>> the trunk once 2.1 was released some time in the future
>>>>> - don't change anything officially, but create a "private" 3.0 branch and
>>>>> merge those changes to a future 3.0 version
>>>>
>>>> I'm for solution 1 because it's a PITA to care about many versions.
>>>>
>>>
>>> I'd go for 1 too - BR Maruan
>>
>> Thanks for your input. Let's wait another couple of days maybe until the next
>> weekend before proceeding with any changes.
> Ok, there isn't any other input.
>
> I'm going to rename the trunk version from 2.1-SNAPSHOT to 3.0-SNAPSHOT and I'm
> going to do the same with out JIRA tickets.
Done

>
> BR
> Andreas
>
>>
>> BR
>> Andreas
>>
>>>
>>>
>>>> Tilman
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
>>>> For additional commands, e-mail: dev-help@pdfbox.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
>>> For additional commands, e-mail: dev-help@pdfbox.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
>> For additional commands, e-mail: dev-help@pdfbox.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
> For additional commands, e-mail: dev-help@pdfbox.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: dev-help@pdfbox.apache.org

Re: Branch for new major version?

Posted by Andreas Lehmkuehler <an...@lehmi.de>.
Am 23.03.2017 um 07:50 schrieb Andreas Lehmkuehler:
> Am 21.03.2017 um 19:45 schrieb Maruan Sahyoun:
>>
>>> Am 21.03.2017 um 19:17 schrieb Tilman Hausherr <TH...@t-online.de>:
>>>
>>> Am 21.03.2017 um 17:53 schrieb Andreas Lehmkuehler:
>>>> Hi,
>>>>
>>>> I'm thinking about implementing some stuff which would most likely require a
>>>> new major version. Obviously there are some similar things which already
>>>> came up, e.g. remove some disturbing public constants, switch to java 7 to
>>>> use twelve monkeys lib.
>>>>
>>>> The question is, how should we deal with that. I see a handful of possible
>>>> ways:
>>>>
>>>> - switch the current trunk to 3.0 and omit 2.1 (for now there are 3 tickets
>>>> with "Fix version/s" 2.1 which didn't make it to the 2.0 branch for
>>>> different reasons)
>>>> - create a 2.1 branch based on the current trunk and switch the current
>>>> trunk to 3.0
>>>> - create a 3.0 branch and don't change anything else. Merge all changes to
>>>> the trunk once 2.1 was released some time in the future
>>>> - don't change anything officially, but create a "private" 3.0 branch and
>>>> merge those changes to a future 3.0 version
>>>
>>> I'm for solution 1 because it's a PITA to care about many versions.
>>>
>>
>> I'd go for 1 too - BR Maruan
>
> Thanks for your input. Let's wait another couple of days maybe until the next
> weekend before proceeding with any changes.
Ok, there isn't any other input.

I'm going to rename the trunk version from 2.1-SNAPSHOT to 3.0-SNAPSHOT and I'm 
going to do the same with out JIRA tickets.

BR
Andreas

>
> BR
> Andreas
>
>>
>>
>>> Tilman
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
>>> For additional commands, e-mail: dev-help@pdfbox.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
>> For additional commands, e-mail: dev-help@pdfbox.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
> For additional commands, e-mail: dev-help@pdfbox.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: dev-help@pdfbox.apache.org

Re: Branch for new major version?

Posted by Andreas Lehmkuehler <an...@lehmi.de>.
Am 21.03.2017 um 19:45 schrieb Maruan Sahyoun:
>
>> Am 21.03.2017 um 19:17 schrieb Tilman Hausherr <TH...@t-online.de>:
>>
>> Am 21.03.2017 um 17:53 schrieb Andreas Lehmkuehler:
>>> Hi,
>>>
>>> I'm thinking about implementing some stuff which would most likely require a new major version. Obviously there are some similar things which already came up, e.g. remove some disturbing public constants, switch to java 7 to use twelve monkeys lib.
>>>
>>> The question is, how should we deal with that. I see a handful of possible ways:
>>>
>>> - switch the current trunk to 3.0 and omit 2.1 (for now there are 3 tickets with "Fix version/s" 2.1 which didn't make it to the 2.0 branch for different reasons)
>>> - create a 2.1 branch based on the current trunk and switch the current trunk to 3.0
>>> - create a 3.0 branch and don't change anything else. Merge all changes to the trunk once 2.1 was released some time in the future
>>> - don't change anything officially, but create a "private" 3.0 branch and merge those changes to a future 3.0 version
>>
>> I'm for solution 1 because it's a PITA to care about many versions.
>>
>
> I'd go for 1 too - BR Maruan

Thanks for your input. Let's wait another couple of days maybe until the next 
weekend before proceeding with any changes.

BR
Andreas

>
>
>> Tilman
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
>> For additional commands, e-mail: dev-help@pdfbox.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
> For additional commands, e-mail: dev-help@pdfbox.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: dev-help@pdfbox.apache.org

Re: Branch for new major version?

Posted by Maruan Sahyoun <sa...@fileaffairs.de>.
> Am 21.03.2017 um 19:17 schrieb Tilman Hausherr <TH...@t-online.de>:
> 
> Am 21.03.2017 um 17:53 schrieb Andreas Lehmkuehler:
>> Hi,
>> 
>> I'm thinking about implementing some stuff which would most likely require a new major version. Obviously there are some similar things which already came up, e.g. remove some disturbing public constants, switch to java 7 to use twelve monkeys lib.
>> 
>> The question is, how should we deal with that. I see a handful of possible ways:
>> 
>> - switch the current trunk to 3.0 and omit 2.1 (for now there are 3 tickets with "Fix version/s" 2.1 which didn't make it to the 2.0 branch for different reasons)
>> - create a 2.1 branch based on the current trunk and switch the current trunk to 3.0
>> - create a 3.0 branch and don't change anything else. Merge all changes to the trunk once 2.1 was released some time in the future
>> - don't change anything officially, but create a "private" 3.0 branch and merge those changes to a future 3.0 version 
> 
> I'm for solution 1 because it's a PITA to care about many versions.
> 

I'd go for 1 too - BR Maruan


> Tilman
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
> For additional commands, e-mail: dev-help@pdfbox.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: dev-help@pdfbox.apache.org

Re: Branch for new major version?

Posted by Tilman Hausherr <TH...@t-online.de>.
Am 21.03.2017 um 17:53 schrieb Andreas Lehmkuehler:
> Hi,
>
> I'm thinking about implementing some stuff which would most likely 
> require a new major version. Obviously there are some similar things 
> which already came up, e.g. remove some disturbing public constants, 
> switch to java 7 to use twelve monkeys lib.
>
> The question is, how should we deal with that. I see a handful of 
> possible ways:
>
> - switch the current trunk to 3.0 and omit 2.1 (for now there are 3 
> tickets with "Fix version/s" 2.1 which didn't make it to the 2.0 
> branch for different reasons)
> - create a 2.1 branch based on the current trunk and switch the 
> current trunk to 3.0
> - create a 3.0 branch and don't change anything else. Merge all 
> changes to the trunk once 2.1 was released some time in the future
> - don't change anything officially, but create a "private" 3.0 branch 
> and merge those changes to a future 3.0 version 

I'm for solution 1 because it's a PITA to care about many versions.

Tilman


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: dev-help@pdfbox.apache.org