Johannes Raggam schreef op 30-10-13 21:00:
On Mit, 2013-10-30 at 12:26 -0700, ajung wrote:
"Our" versioning schema refers to Plone?
This one, which should become the Plone coding conventions:
https://github.com/plone/plone.api/blob/master/docs/contribute/conventions.rst#versioning-scheme
I'd
On Mit, 2013-10-30 at 22:16 +0100, Guido Stevens wrote:
> Oops correction: 1.2.3dev > 1.2.3rc1
no, 1.2.3.dev < 1.2.3.rc1 < 1.2.3.rcdev
I got hit by naming plone.event 1.0dev and depending on >=1.0rc1
I updated the versioning scheme secion in plone.api's convention doc:
https://github.com/plone/pl
I can feel your pain and am +1 with you on that
my personal experience is that 4.2 to 4.3 is more painful than i expected :(
On Thu, Oct 31, 2013 at 10:31 AM, Andreas Jung wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
>
> Christian Ledermann wrote:
>> On Thu, Oct 31, 2013 at 9:48 A
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Christian Ledermann wrote:
> On Thu, Oct 31, 2013 at 9:48 AM, Andreas Jung
> wrote:
>
>
> Christian Ledermann wrote:
On Thu, Oct 31, 2013 at 8:37 AM, Andreas Jung
wrote: David Glick (Plone) wrote:
>>> On 10/30/13, 12:17 PM, Héctor V
On Thu, Oct 31, 2013 at 9:48 AM, Andreas Jung wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
>
> Christian Ledermann wrote:
>> On Thu, Oct 31, 2013 at 8:37 AM, Andreas Jung
>> wrote: David Glick (Plone) wrote:
> On 10/30/13, 12:17 PM, Héctor Velarde wrote:
>> according to ou
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Christian Ledermann wrote:
> On Thu, Oct 31, 2013 at 8:37 AM, Andreas Jung
> wrote: David Glick (Plone) wrote:
On 10/30/13, 12:17 PM, Héctor Velarde wrote:
> according to our versioning scheme conventions, we should do
> the following:
On Thu, Oct 31, 2013 at 8:37 AM, Andreas Jung wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> David Glick (Plone) wrote:
>> On 10/30/13, 12:17 PM, Héctor Velarde wrote:
>>> according to our versioning scheme conventions, we should do the
>>> following:
>>>
>>> Given a version number M
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David Glick (Plone) wrote:
> On 10/30/13, 12:17 PM, Héctor Velarde wrote:
>> according to our versioning scheme conventions, we should do the
>> following:
>>
>> Given a version number MAJOR.MINOR.PATCH, increment the:
>>
>> * MAJOR version when you
Oops correction: 1.2.3dev > 1.2.3rc1
1.2.3rc1 = 1.2.3.rc1 = 1.2.3-rc1 = 1.2.3.c
rc = .rc = -rc = c
dev follows c
So using .dev as if it were equal or before alpha is faulty. A dev release is
between beta and final.
--
Guido Stevens | +31.43.3618933 | http://cosent.nl
s o c i a l k
On 30 okt. 2013, at 21:00, Johannes Raggam wrote:
> Regarding versioning schemes: Comparing the versioning scheme section
> described in conventions.rst, which I wrote and the scheme described on
> http://semver.org/ - there are some differences regarding pre-release
> versions. They require p
On Mit, 2013-10-30 at 12:26 -0700, ajung wrote:
> "Our" versioning schema refers to Plone?
This one, which should become the Plone coding conventions:
https://github.com/plone/plone.api/blob/master/docs/contribute/conventions.rst#versioning-scheme
I'd do a PATCH increment. But if a package only h
HV> this is the Plone Product Developers, isn't it?
http://developer.plone.org/reference_manuals/external/plone.api/contribute/conventions.html#versioning-scheme
see what happens when you miss a Plone Conference?
Héctor Velarde
On 30-10-2013 17:26, ajung wrote:
"Our" versioning schema refers
On 10/30/13, 12:17 PM, Héctor Velarde wrote:
according to our versioning scheme conventions, we should do the
following:
Given a version number MAJOR.MINOR.PATCH, increment the:
* MAJOR version when you make incompatible API changes,
* MINOR version when you add functionality in a backwards-co
"Our" versioning schema refers to Plone?
-aj
hvelarde wrote
> according to our versioning scheme conventions, we should do the
> following:
>
> Given a version number MAJOR.MINOR.PATCH, increment the:
>
> * MAJOR version when you make incompatible API changes,
> * MINOR version when you add fu
according to our versioning scheme conventions, we should do the following:
Given a version number MAJOR.MINOR.PATCH, increment the:
* MAJOR version when you make incompatible API changes,
* MINOR version when you add functionality in a backwards-compatible
manner, and
* PATCH version when you
15 matches
Mail list logo