Quantcast

Proper way of incrementing the version in Git?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Proper way of incrementing the version in Git?

Dan Little-2
Anyone have thoughts on this?

1. We drop a version (say 2.8.2).  When doing this the RM ensures that
version is marked properly in the HTML pages.

2. We move on to coding new features, bug fixes, etc.

3. The Demo still says 2.8.2 even though it is definitely not 2.8.2.

The "3.0 answer" is "The build system sets the right variables and
it's substituted in the build files". The 2.X answer will probably
remain more human instensive.
_______________________________________________
geomoose-psc mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geomoose-psc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proper way of incrementing the version in Git?

James Klassen-2

IMHO a new build system has nothing to do with it in so far as it is already partially automated.

The real question is when do we update the version (in the html and docs or in a central variable).

I think that it would be less confusing if master and the release branches are updated in git immediately after the release so that people don't confuse them as the same as the tagged release.

The only issue I see is we may not know what the next release should be called (patch or minor or major update).  Ideally this wouldn't matter because it would be determined by branch (eg the 2.8 branch can only have the next 2.8.x+1 release) while master is always ahead at least a minor.

On Apr 12, 2016 4:26 PM, "Dan Little" <[hidden email]> wrote:
Anyone have thoughts on this?

1. We drop a version (say 2.8.2).  When doing this the RM ensures that
version is marked properly in the HTML pages.

2. We move on to coding new features, bug fixes, etc.

3. The Demo still says 2.8.2 even though it is definitely not 2.8.2.

The "3.0 answer" is "The build system sets the right variables and
it's substituted in the build files". The 2.X answer will probably
remain more human instensive.
_______________________________________________
geomoose-psc mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geomoose-psc

_______________________________________________
geomoose-psc mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geomoose-psc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proper way of incrementing the version in Git?

Dan Little-2
On one of my projects, the "Makefile" takes a version string in and
all of the compiled templates/javascript/css get that version placed
in the file. The repository does not contain any of the compiled
versions of the code.

On another, "master" is never used and Dev happens in a different
branch at almost all times.  We don't do semantic versioning for that
project.  Versions are time based as we release new versions
quarterly.

On Tue, Apr 12, 2016 at 5:01 PM, James Klassen <[hidden email]> wrote:

> IMHO a new build system has nothing to do with it in so far as it is already
> partially automated.
>
> The real question is when do we update the version (in the html and docs or
> in a central variable).
>
> I think that it would be less confusing if master and the release branches
> are updated in git immediately after the release so that people don't
> confuse them as the same as the tagged release.
>
> The only issue I see is we may not know what the next release should be
> called (patch or minor or major update).  Ideally this wouldn't matter
> because it would be determined by branch (eg the 2.8 branch can only have
> the next 2.8.x+1 release) while master is always ahead at least a minor.
>
> On Apr 12, 2016 4:26 PM, "Dan Little" <[hidden email]> wrote:
>
> Anyone have thoughts on this?
>
> 1. We drop a version (say 2.8.2).  When doing this the RM ensures that
> version is marked properly in the HTML pages.
>
> 2. We move on to coding new features, bug fixes, etc.
>
> 3. The Demo still says 2.8.2 even though it is definitely not 2.8.2.
>
> The "3.0 answer" is "The build system sets the right variables and
> it's substituted in the build files". The 2.X answer will probably
> remain more human instensive.
> _______________________________________________
> geomoose-psc mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/geomoose-psc
_______________________________________________
geomoose-psc mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geomoose-psc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proper way of incrementing the version in Git?

James Klassen-2

Isn't the makefile in the repo or does the makefile get the version from a tag/user input?

On Apr 12, 2016 5:05 PM, "Dan Little" <[hidden email]> wrote:
On one of my projects, the "Makefile" takes a version string in and
all of the compiled templates/javascript/css get that version placed
in the file. The repository does not contain any of the compiled
versions of the code.

On another, "master" is never used and Dev happens in a different
branch at almost all times.  We don't do semantic versioning for that
project.  Versions are time based as we release new versions
quarterly.

On Tue, Apr 12, 2016 at 5:01 PM, James Klassen <[hidden email]> wrote:
> IMHO a new build system has nothing to do with it in so far as it is already
> partially automated.
>
> The real question is when do we update the version (in the html and docs or
> in a central variable).
>
> I think that it would be less confusing if master and the release branches
> are updated in git immediately after the release so that people don't
> confuse them as the same as the tagged release.
>
> The only issue I see is we may not know what the next release should be
> called (patch or minor or major update).  Ideally this wouldn't matter
> because it would be determined by branch (eg the 2.8 branch can only have
> the next 2.8.x+1 release) while master is always ahead at least a minor.
>
> On Apr 12, 2016 4:26 PM, "Dan Little" <[hidden email]> wrote:
>
> Anyone have thoughts on this?
>
> 1. We drop a version (say 2.8.2).  When doing this the RM ensures that
> version is marked properly in the HTML pages.
>
> 2. We move on to coding new features, bug fixes, etc.
>
> 3. The Demo still says 2.8.2 even though it is definitely not 2.8.2.
>
> The "3.0 answer" is "The build system sets the right variables and
> it's substituted in the build files". The 2.X answer will probably
> remain more human instensive.
> _______________________________________________
> geomoose-psc mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/geomoose-psc

_______________________________________________
geomoose-psc mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geomoose-psc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proper way of incrementing the version in Git?

Dan Little-2
The "Makefile" is in the repo and takes in a version.  I say
"Makefile" but it's actually a python script which fires off a bunch
of other processes.

On Tue, Apr 12, 2016 at 5:07 PM, James Klassen <[hidden email]> wrote:

> Isn't the makefile in the repo or does the makefile get the version from a
> tag/user input?
>
> On Apr 12, 2016 5:05 PM, "Dan Little" <[hidden email]> wrote:
>>
>> On one of my projects, the "Makefile" takes a version string in and
>> all of the compiled templates/javascript/css get that version placed
>> in the file. The repository does not contain any of the compiled
>> versions of the code.
>>
>> On another, "master" is never used and Dev happens in a different
>> branch at almost all times.  We don't do semantic versioning for that
>> project.  Versions are time based as we release new versions
>> quarterly.
>>
>> On Tue, Apr 12, 2016 at 5:01 PM, James Klassen <[hidden email]>
>> wrote:
>> > IMHO a new build system has nothing to do with it in so far as it is
>> > already
>> > partially automated.
>> >
>> > The real question is when do we update the version (in the html and docs
>> > or
>> > in a central variable).
>> >
>> > I think that it would be less confusing if master and the release
>> > branches
>> > are updated in git immediately after the release so that people don't
>> > confuse them as the same as the tagged release.
>> >
>> > The only issue I see is we may not know what the next release should be
>> > called (patch or minor or major update).  Ideally this wouldn't matter
>> > because it would be determined by branch (eg the 2.8 branch can only
>> > have
>> > the next 2.8.x+1 release) while master is always ahead at least a minor.
>> >
>> > On Apr 12, 2016 4:26 PM, "Dan Little" <[hidden email]> wrote:
>> >
>> > Anyone have thoughts on this?
>> >
>> > 1. We drop a version (say 2.8.2).  When doing this the RM ensures that
>> > version is marked properly in the HTML pages.
>> >
>> > 2. We move on to coding new features, bug fixes, etc.
>> >
>> > 3. The Demo still says 2.8.2 even though it is definitely not 2.8.2.
>> >
>> > The "3.0 answer" is "The build system sets the right variables and
>> > it's substituted in the build files". The 2.X answer will probably
>> > remain more human instensive.
>> > _______________________________________________
>> > geomoose-psc mailing list
>> > [hidden email]
>> > http://lists.osgeo.org/mailman/listinfo/geomoose-psc
_______________________________________________
geomoose-psc mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geomoose-psc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proper way of incrementing the version in Git?

James Klassen-2

Ok

On Apr 12, 2016 5:09 PM, "Dan Little" <[hidden email]> wrote:
The "Makefile" is in the repo and takes in a version.  I say
"Makefile" but it's actually a python script which fires off a bunch
of other processes.

On Tue, Apr 12, 2016 at 5:07 PM, James Klassen <[hidden email]> wrote:
> Isn't the makefile in the repo or does the makefile get the version from a
> tag/user input?
>
> On Apr 12, 2016 5:05 PM, "Dan Little" <[hidden email]> wrote:
>>
>> On one of my projects, the "Makefile" takes a version string in and
>> all of the compiled templates/javascript/css get that version placed
>> in the file. The repository does not contain any of the compiled
>> versions of the code.
>>
>> On another, "master" is never used and Dev happens in a different
>> branch at almost all times.  We don't do semantic versioning for that
>> project.  Versions are time based as we release new versions
>> quarterly.
>>
>> On Tue, Apr 12, 2016 at 5:01 PM, James Klassen <[hidden email]>
>> wrote:
>> > IMHO a new build system has nothing to do with it in so far as it is
>> > already
>> > partially automated.
>> >
>> > The real question is when do we update the version (in the html and docs
>> > or
>> > in a central variable).
>> >
>> > I think that it would be less confusing if master and the release
>> > branches
>> > are updated in git immediately after the release so that people don't
>> > confuse them as the same as the tagged release.
>> >
>> > The only issue I see is we may not know what the next release should be
>> > called (patch or minor or major update).  Ideally this wouldn't matter
>> > because it would be determined by branch (eg the 2.8 branch can only
>> > have
>> > the next 2.8.x+1 release) while master is always ahead at least a minor.
>> >
>> > On Apr 12, 2016 4:26 PM, "Dan Little" <[hidden email]> wrote:
>> >
>> > Anyone have thoughts on this?
>> >
>> > 1. We drop a version (say 2.8.2).  When doing this the RM ensures that
>> > version is marked properly in the HTML pages.
>> >
>> > 2. We move on to coding new features, bug fixes, etc.
>> >
>> > 3. The Demo still says 2.8.2 even though it is definitely not 2.8.2.
>> >
>> > The "3.0 answer" is "The build system sets the right variables and
>> > it's substituted in the build files". The 2.X answer will probably
>> > remain more human instensive.
>> > _______________________________________________
>> > geomoose-psc mailing list
>> > [hidden email]
>> > http://lists.osgeo.org/mailman/listinfo/geomoose-psc

_______________________________________________
geomoose-psc mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geomoose-psc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proper way of incrementing the version in Git?

Eli Adam
We have some details (accumulated by mostly noticing things we
forgot), http://geomoose.org/developer/release.html

Trunk could always be some clearly non-release number, 2.x, 2.#,
2-dev, etc.  And numbers only get assigned in releases when they
happen.

I think that GDAL added a future/fake date to trunk after repeated
confusion of whether it had been released or not, "GDAL 2.1.0dev,
released 2015/99/99"

Eli

On Tue, Apr 12, 2016 at 5:15 PM, James Klassen <[hidden email]> wrote:

> Ok
>
> On Apr 12, 2016 5:09 PM, "Dan Little" <[hidden email]> wrote:
>>
>> The "Makefile" is in the repo and takes in a version.  I say
>> "Makefile" but it's actually a python script which fires off a bunch
>> of other processes.
>>
>> On Tue, Apr 12, 2016 at 5:07 PM, James Klassen <[hidden email]>
>> wrote:
>> > Isn't the makefile in the repo or does the makefile get the version from
>> > a
>> > tag/user input?
>> >
>> > On Apr 12, 2016 5:05 PM, "Dan Little" <[hidden email]> wrote:
>> >>
>> >> On one of my projects, the "Makefile" takes a version string in and
>> >> all of the compiled templates/javascript/css get that version placed
>> >> in the file. The repository does not contain any of the compiled
>> >> versions of the code.
>> >>
>> >> On another, "master" is never used and Dev happens in a different
>> >> branch at almost all times.  We don't do semantic versioning for that
>> >> project.  Versions are time based as we release new versions
>> >> quarterly.
>> >>
>> >> On Tue, Apr 12, 2016 at 5:01 PM, James Klassen <[hidden email]>
>> >> wrote:
>> >> > IMHO a new build system has nothing to do with it in so far as it is
>> >> > already
>> >> > partially automated.
>> >> >
>> >> > The real question is when do we update the version (in the html and
>> >> > docs
>> >> > or
>> >> > in a central variable).
>> >> >
>> >> > I think that it would be less confusing if master and the release
>> >> > branches
>> >> > are updated in git immediately after the release so that people don't
>> >> > confuse them as the same as the tagged release.
>> >> >
>> >> > The only issue I see is we may not know what the next release should
>> >> > be
>> >> > called (patch or minor or major update).  Ideally this wouldn't
>> >> > matter
>> >> > because it would be determined by branch (eg the 2.8 branch can only
>> >> > have
>> >> > the next 2.8.x+1 release) while master is always ahead at least a
>> >> > minor.
>> >> >
>> >> > On Apr 12, 2016 4:26 PM, "Dan Little" <[hidden email]>
>> >> > wrote:
>> >> >
>> >> > Anyone have thoughts on this?
>> >> >
>> >> > 1. We drop a version (say 2.8.2).  When doing this the RM ensures
>> >> > that
>> >> > version is marked properly in the HTML pages.
>> >> >
>> >> > 2. We move on to coding new features, bug fixes, etc.
>> >> >
>> >> > 3. The Demo still says 2.8.2 even though it is definitely not 2.8.2.
>> >> >
>> >> > The "3.0 answer" is "The build system sets the right variables and
>> >> > it's substituted in the build files". The 2.X answer will probably
>> >> > remain more human instensive.
>> >> > _______________________________________________
>> >> > geomoose-psc mailing list
>> >> > [hidden email]
>> >> > http://lists.osgeo.org/mailman/listinfo/geomoose-psc
>
>
> _______________________________________________
> geomoose-psc mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/geomoose-psc
_______________________________________________
geomoose-psc mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geomoose-psc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proper way of incrementing the version in Git?

Dan Little-2
As much as I loathe unnecessary commits (and SVN carry over I think)
it's probably good for us to do a "change version commit" then
"release commit" then "change version to  something indicating dev
commit".

Should this be made an RFC? An RFC addendum/clarifier? Or something we
just "know Jim does"?

On Tue, Apr 12, 2016 at 11:37 PM, Eli Adam <[hidden email]> wrote:

> We have some details (accumulated by mostly noticing things we
> forgot), http://geomoose.org/developer/release.html
>
> Trunk could always be some clearly non-release number, 2.x, 2.#,
> 2-dev, etc.  And numbers only get assigned in releases when they
> happen.
>
> I think that GDAL added a future/fake date to trunk after repeated
> confusion of whether it had been released or not, "GDAL 2.1.0dev,
> released 2015/99/99"
>
> Eli
>
> On Tue, Apr 12, 2016 at 5:15 PM, James Klassen <[hidden email]> wrote:
>> Ok
>>
>> On Apr 12, 2016 5:09 PM, "Dan Little" <[hidden email]> wrote:
>>>
>>> The "Makefile" is in the repo and takes in a version.  I say
>>> "Makefile" but it's actually a python script which fires off a bunch
>>> of other processes.
>>>
>>> On Tue, Apr 12, 2016 at 5:07 PM, James Klassen <[hidden email]>
>>> wrote:
>>> > Isn't the makefile in the repo or does the makefile get the version from
>>> > a
>>> > tag/user input?
>>> >
>>> > On Apr 12, 2016 5:05 PM, "Dan Little" <[hidden email]> wrote:
>>> >>
>>> >> On one of my projects, the "Makefile" takes a version string in and
>>> >> all of the compiled templates/javascript/css get that version placed
>>> >> in the file. The repository does not contain any of the compiled
>>> >> versions of the code.
>>> >>
>>> >> On another, "master" is never used and Dev happens in a different
>>> >> branch at almost all times.  We don't do semantic versioning for that
>>> >> project.  Versions are time based as we release new versions
>>> >> quarterly.
>>> >>
>>> >> On Tue, Apr 12, 2016 at 5:01 PM, James Klassen <[hidden email]>
>>> >> wrote:
>>> >> > IMHO a new build system has nothing to do with it in so far as it is
>>> >> > already
>>> >> > partially automated.
>>> >> >
>>> >> > The real question is when do we update the version (in the html and
>>> >> > docs
>>> >> > or
>>> >> > in a central variable).
>>> >> >
>>> >> > I think that it would be less confusing if master and the release
>>> >> > branches
>>> >> > are updated in git immediately after the release so that people don't
>>> >> > confuse them as the same as the tagged release.
>>> >> >
>>> >> > The only issue I see is we may not know what the next release should
>>> >> > be
>>> >> > called (patch or minor or major update).  Ideally this wouldn't
>>> >> > matter
>>> >> > because it would be determined by branch (eg the 2.8 branch can only
>>> >> > have
>>> >> > the next 2.8.x+1 release) while master is always ahead at least a
>>> >> > minor.
>>> >> >
>>> >> > On Apr 12, 2016 4:26 PM, "Dan Little" <[hidden email]>
>>> >> > wrote:
>>> >> >
>>> >> > Anyone have thoughts on this?
>>> >> >
>>> >> > 1. We drop a version (say 2.8.2).  When doing this the RM ensures
>>> >> > that
>>> >> > version is marked properly in the HTML pages.
>>> >> >
>>> >> > 2. We move on to coding new features, bug fixes, etc.
>>> >> >
>>> >> > 3. The Demo still says 2.8.2 even though it is definitely not 2.8.2.
>>> >> >
>>> >> > The "3.0 answer" is "The build system sets the right variables and
>>> >> > it's substituted in the build files". The 2.X answer will probably
>>> >> > remain more human instensive.
>>> >> > _______________________________________________
>>> >> > geomoose-psc mailing list
>>> >> > [hidden email]
>>> >> > http://lists.osgeo.org/mailman/listinfo/geomoose-psc
>>
>>
>> _______________________________________________
>> geomoose-psc mailing list
>> [hidden email]
>> http://lists.osgeo.org/mailman/listinfo/geomoose-psc
_______________________________________________
geomoose-psc mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geomoose-psc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proper way of incrementing the version in Git?

James Klassen-2
The update should probably go here [1] (which also documents how things
are being built on the demo server).

[1] http://www.geomoose.org/developer/release.html

On 04/13/2016 10:09 AM, Dan Little wrote:

> As much as I loathe unnecessary commits (and SVN carry over I think)
> it's probably good for us to do a "change version commit" then
> "release commit" then "change version to  something indicating dev
> commit".
>
> Should this be made an RFC? An RFC addendum/clarifier? Or something we
> just "know Jim does"?
>
> On Tue, Apr 12, 2016 at 11:37 PM, Eli Adam <[hidden email]> wrote:
>> We have some details (accumulated by mostly noticing things we
>> forgot), http://geomoose.org/developer/release.html
>>
>> Trunk could always be some clearly non-release number, 2.x, 2.#,
>> 2-dev, etc.  And numbers only get assigned in releases when they
>> happen.
>>
>> I think that GDAL added a future/fake date to trunk after repeated
>> confusion of whether it had been released or not, "GDAL 2.1.0dev,
>> released 2015/99/99"
>>
>> Eli
>>
>> On Tue, Apr 12, 2016 at 5:15 PM, James Klassen <[hidden email]> wrote:
>>> Ok
>>>
>>> On Apr 12, 2016 5:09 PM, "Dan Little" <[hidden email]> wrote:
>>>> The "Makefile" is in the repo and takes in a version.  I say
>>>> "Makefile" but it's actually a python script which fires off a bunch
>>>> of other processes.
>>>>
>>>> On Tue, Apr 12, 2016 at 5:07 PM, James Klassen <[hidden email]>
>>>> wrote:
>>>>> Isn't the makefile in the repo or does the makefile get the version from
>>>>> a
>>>>> tag/user input?
>>>>>
>>>>> On Apr 12, 2016 5:05 PM, "Dan Little" <[hidden email]> wrote:
>>>>>> On one of my projects, the "Makefile" takes a version string in and
>>>>>> all of the compiled templates/javascript/css get that version placed
>>>>>> in the file. The repository does not contain any of the compiled
>>>>>> versions of the code.
>>>>>>
>>>>>> On another, "master" is never used and Dev happens in a different
>>>>>> branch at almost all times.  We don't do semantic versioning for that
>>>>>> project.  Versions are time based as we release new versions
>>>>>> quarterly.
>>>>>>
>>>>>> On Tue, Apr 12, 2016 at 5:01 PM, James Klassen <[hidden email]>
>>>>>> wrote:
>>>>>>> IMHO a new build system has nothing to do with it in so far as it is
>>>>>>> already
>>>>>>> partially automated.
>>>>>>>
>>>>>>> The real question is when do we update the version (in the html and
>>>>>>> docs
>>>>>>> or
>>>>>>> in a central variable).
>>>>>>>
>>>>>>> I think that it would be less confusing if master and the release
>>>>>>> branches
>>>>>>> are updated in git immediately after the release so that people don't
>>>>>>> confuse them as the same as the tagged release.
>>>>>>>
>>>>>>> The only issue I see is we may not know what the next release should
>>>>>>> be
>>>>>>> called (patch or minor or major update).  Ideally this wouldn't
>>>>>>> matter
>>>>>>> because it would be determined by branch (eg the 2.8 branch can only
>>>>>>> have
>>>>>>> the next 2.8.x+1 release) while master is always ahead at least a
>>>>>>> minor.
>>>>>>>
>>>>>>> On Apr 12, 2016 4:26 PM, "Dan Little" <[hidden email]>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Anyone have thoughts on this?
>>>>>>>
>>>>>>> 1. We drop a version (say 2.8.2).  When doing this the RM ensures
>>>>>>> that
>>>>>>> version is marked properly in the HTML pages.
>>>>>>>
>>>>>>> 2. We move on to coding new features, bug fixes, etc.
>>>>>>>
>>>>>>> 3. The Demo still says 2.8.2 even though it is definitely not 2.8.2.
>>>>>>>
>>>>>>> The "3.0 answer" is "The build system sets the right variables and
>>>>>>> it's substituted in the build files". The 2.X answer will probably
>>>>>>> remain more human instensive.
>>>>>>> _______________________________________________
>>>>>>> geomoose-psc mailing list
>>>>>>> [hidden email]
>>>>>>> http://lists.osgeo.org/mailman/listinfo/geomoose-psc
>>>
>>> _______________________________________________
>>> geomoose-psc mailing list
>>> [hidden email]
>>> http://lists.osgeo.org/mailman/listinfo/geomoose-psc

_______________________________________________
geomoose-psc mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geomoose-psc
Loading...