You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Pierre-Luc Dion <pd...@cloudops.com> on 2014/04/15 14:54:46 UTC
release note documentation
At the hackathon of CCCNA14 with Sebastien, we made few tests the RTD for
documentation versioning.
Look like we can use branch instead of tag for versioning and we can also
select which branches are published on RTD.org
So, in order to have doc version match product version, would it make sense
to create a branch call 4.3.0 for the current CS version and start updating
master for next version 4.4 ? once we will have 4.4 pretty much ready we
will be able to create new branch 4.4.
By using branches it allow us to update documentation without having to
update is version.
Make sense? Have we missing a potential GIT behaviour doing it this way?
Pierre-Luc Dion
Architecte de Solution Cloud | Cloud Solutions Architect
855-OK-CLOUD (855-652-5683) x1101
- - -
*CloudOps*420 rue Guy
Montréal QC H3J 1S6
www.cloudops.com
@CloudOps_
Re: release note documentation
Posted by Pierre-Luc Dion <pd...@cloudops.com>.
at this point do we have to create a new [discuss] thread? I'm still not
familiar with Apache process so I can start a new thread.
I would also add few consideration.
by using branches, let say we create a branch 4.3 for current CS version,
this branch would be the default visible on RTD and we wouldn't see latest
anymore, the master branch would be the work in progress for version 4.4 of
CS. although, if we have a need for 4.3.1, then we would have to create a
branch 4.3.1 and update doc so it reflect new fixes, instructions,....
master and 4.3.1 branch would not be visible on RTD until the CS version is
released, but branches would be available on the GIT repo.
This way, we can work on the release-note documentation as the CS version
is under development, this RN is not visible from RTD because the CS
version is not released but it is available in the gitrepo as master branch
or sub version branch. So on RTD we would only see RN of Released version
of CloudStack.
if typo or upgrade notes have to be corrected on RN of release CloudStack
Version, those fix would have to be performed on the branch directly and
the branch would have to be rebuild in RTD, this would not change the
documentation version show on RTD.
I guest this working method need a vote? at lease a [discuss] ? but if
someone need fixes in RN, example: fix typo, this wouldn't require vote
right?
Pierre-Luc Dion
Architecte de Solution Cloud | Cloud Solutions Architect
855-OK-CLOUD (855-652-5683) x1101
- - -
*CloudOps*420 rue Guy
Montréal QC H3J 1S6
www.cloudops.com
@CloudOps_
On Thu, Apr 17, 2014 at 12:03 PM, sebgoa <ru...@gmail.com> wrote:
>
> On Apr 17, 2014, at 5:57 PM, David Nalley <da...@gnsa.us> wrote:
>
> > Are you shipping (e.g. making source available for download) tarballs
> > or merely producing documentation that we publish publicly.
> > If the answer to that is no; then we don't need votes or a formal
> > release process (anymore than we need votes for publishing content to
> > cloudstack.apache.org
>
> -sources are available through the asf git repo and the github mirror.
> -we do not make docs tar ball or packages.
> -we do build pdf and potentially epub that people can download
>
> As a matter of fact since the build and publishing platform is external to
> ASF infra, we (I since it's my RTD account) are just consuming the docs
> from git and providing it to the community like we do with .debs and .rpms .
>
> Good point David,
>
> >
> > --David
> >
> > On Thu, Apr 17, 2014 at 11:43 AM, sebgoa <ru...@gmail.com> wrote:
> >>
> >> On Apr 17, 2014, at 5:31 PM, Pierre-Luc Dion <pd...@cloudops.com>
> wrote:
> >>
> >>> Should we have a page on wiki explaining how we would handle
> release-notes
> >>> on RTD ? and then vote on the method?
> >>> I'm not seeing other alternative to branches exept having one RTD
> project
> >>> for each release-notes.
> >>>
> >>
> >> I think your email here explains it well.
> >>
> >> What we need now is a [DISCUSS] thread on whether we want to vote on
> docs releases and whether we need a formal release process or not ?
> >>
> >> Do you want to start that thread ;)
> >>
> >>>
> >>>
> >>>
> >>>
> >>> Pierre-Luc Dion
> >>> Architecte de Solution Cloud | Cloud Solutions Architect
> >>> 855-OK-CLOUD (855-652-5683) x1101
> >>> - - -
> >>>
> >>> *CloudOps*420 rue Guy
> >>> Montréal QC H3J 1S6
> >>> www.cloudops.com
> >>> @CloudOps_
> >>>
> >>>
> >>> On Tue, Apr 15, 2014 at 12:28 PM, David Nalley <da...@gnsa.us> wrote:
> >>>
> >>>> So I think it makes sense for most documents to point to feature
> >>>> version (e.g. 4.3 branch, 4.4 branch.) E.g. docs for 4.3.1 should be
> >>>> materially the same as 4.3.0 from a docs standpoint. Release notes are
> >>>> the exception here, though perhaps they could be dealt with in an
> >>>> additive way.
> >>>>
> >>>> --David
> >>>>
> >>>> On Tue, Apr 15, 2014 at 11:17 AM, sebgoa <ru...@gmail.com> wrote:
> >>>>> To add to what Pierre-Luc said:
> >>>>>
> >>>>> Readthedocs has something they call "releases" but those are in fact
> >>>> builds that point to a branch. Not a specific tag.
> >>>>>
> >>>>> So the release version of the doc we would see on the website will be
> >>>> the live state of the release branch, not a tag that we could vote on.
> >>>>>
> >>>>> That said, we have not yet discussed whether or not we need to
> formally
> >>>> vote on doc releases :)
> >>>>>
> >>>>> -sebastien
> >>>>>
> >>>>>
> >>>>> On Apr 15, 2014, at 3:56 PM, Daan Hoogland <da...@gmail.com>
> >>>> wrote:
> >>>>>
> >>>>>> makes sense! the only behavior that needs to be taken into account
> is
> >>>>>> that of any publication scripts that we might write. So it seems to
> me
> >>>>>> this is the best result we have from this version of the hackathon
> :(
> >>>>>> & :)
> >>>>>>
> >>>>>> On Tue, Apr 15, 2014 at 2:54 PM, Pierre-Luc Dion <
> pdion@cloudops.com>
> >>>> wrote:
> >>>>>>> At the hackathon of CCCNA14 with Sebastien, we made few tests the
> RTD
> >>>> for
> >>>>>>> documentation versioning.
> >>>>>>>
> >>>>>>> Look like we can use branch instead of tag for versioning and we
> can
> >>>> also
> >>>>>>> select which branches are published on RTD.org
> >>>>>>>
> >>>>>>> So, in order to have doc version match product version, would it
> make
> >>>> sense
> >>>>>>> to create a branch call 4.3.0 for the current CS version and start
> >>>> updating
> >>>>>>> master for next version 4.4 ? once we will have 4.4 pretty much
> ready
> >>>> we
> >>>>>>> will be able to create new branch 4.4.
> >>>>>>>
> >>>>>>> By using branches it allow us to update documentation without
> having to
> >>>>>>> update is version.
> >>>>>>>
> >>>>>>> Make sense? Have we missing a potential GIT behaviour doing it
> this
> >>>> way?
> >>>>>>>
> >>>>>>>
> >>>>>>> Pierre-Luc Dion
> >>>>>>> Architecte de Solution Cloud | Cloud Solutions Architect
> >>>>>>> 855-OK-CLOUD (855-652-5683) x1101
> >>>>>>> - - -
> >>>>>>>
> >>>>>>> *CloudOps*420 rue Guy
> >>>>>>> Montréal QC H3J 1S6
> >>>>>>> www.cloudops.com
> >>>>>>> @CloudOps_
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Daan
> >>>>>
> >>>>
> >>
>
>
Re: release note documentation
Posted by sebgoa <ru...@gmail.com>.
On Apr 17, 2014, at 5:57 PM, David Nalley <da...@gnsa.us> wrote:
> Are you shipping (e.g. making source available for download) tarballs
> or merely producing documentation that we publish publicly.
> If the answer to that is no; then we don't need votes or a formal
> release process (anymore than we need votes for publishing content to
> cloudstack.apache.org
-sources are available through the asf git repo and the github mirror.
-we do not make docs tar ball or packages.
-we do build pdf and potentially epub that people can download
As a matter of fact since the build and publishing platform is external to ASF infra, we (I since it's my RTD account) are just consuming the docs from git and providing it to the community like we do with .debs and .rpms .
Good point David,
>
> --David
>
> On Thu, Apr 17, 2014 at 11:43 AM, sebgoa <ru...@gmail.com> wrote:
>>
>> On Apr 17, 2014, at 5:31 PM, Pierre-Luc Dion <pd...@cloudops.com> wrote:
>>
>>> Should we have a page on wiki explaining how we would handle release-notes
>>> on RTD ? and then vote on the method?
>>> I'm not seeing other alternative to branches exept having one RTD project
>>> for each release-notes.
>>>
>>
>> I think your email here explains it well.
>>
>> What we need now is a [DISCUSS] thread on whether we want to vote on docs releases and whether we need a formal release process or not ?
>>
>> Do you want to start that thread ;)
>>
>>>
>>>
>>>
>>>
>>> Pierre-Luc Dion
>>> Architecte de Solution Cloud | Cloud Solutions Architect
>>> 855-OK-CLOUD (855-652-5683) x1101
>>> - - -
>>>
>>> *CloudOps*420 rue Guy
>>> Montréal QC H3J 1S6
>>> www.cloudops.com
>>> @CloudOps_
>>>
>>>
>>> On Tue, Apr 15, 2014 at 12:28 PM, David Nalley <da...@gnsa.us> wrote:
>>>
>>>> So I think it makes sense for most documents to point to feature
>>>> version (e.g. 4.3 branch, 4.4 branch.) E.g. docs for 4.3.1 should be
>>>> materially the same as 4.3.0 from a docs standpoint. Release notes are
>>>> the exception here, though perhaps they could be dealt with in an
>>>> additive way.
>>>>
>>>> --David
>>>>
>>>> On Tue, Apr 15, 2014 at 11:17 AM, sebgoa <ru...@gmail.com> wrote:
>>>>> To add to what Pierre-Luc said:
>>>>>
>>>>> Readthedocs has something they call "releases" but those are in fact
>>>> builds that point to a branch. Not a specific tag.
>>>>>
>>>>> So the release version of the doc we would see on the website will be
>>>> the live state of the release branch, not a tag that we could vote on.
>>>>>
>>>>> That said, we have not yet discussed whether or not we need to formally
>>>> vote on doc releases :)
>>>>>
>>>>> -sebastien
>>>>>
>>>>>
>>>>> On Apr 15, 2014, at 3:56 PM, Daan Hoogland <da...@gmail.com>
>>>> wrote:
>>>>>
>>>>>> makes sense! the only behavior that needs to be taken into account is
>>>>>> that of any publication scripts that we might write. So it seems to me
>>>>>> this is the best result we have from this version of the hackathon :(
>>>>>> & :)
>>>>>>
>>>>>> On Tue, Apr 15, 2014 at 2:54 PM, Pierre-Luc Dion <pd...@cloudops.com>
>>>> wrote:
>>>>>>> At the hackathon of CCCNA14 with Sebastien, we made few tests the RTD
>>>> for
>>>>>>> documentation versioning.
>>>>>>>
>>>>>>> Look like we can use branch instead of tag for versioning and we can
>>>> also
>>>>>>> select which branches are published on RTD.org
>>>>>>>
>>>>>>> So, in order to have doc version match product version, would it make
>>>> sense
>>>>>>> to create a branch call 4.3.0 for the current CS version and start
>>>> updating
>>>>>>> master for next version 4.4 ? once we will have 4.4 pretty much ready
>>>> we
>>>>>>> will be able to create new branch 4.4.
>>>>>>>
>>>>>>> By using branches it allow us to update documentation without having to
>>>>>>> update is version.
>>>>>>>
>>>>>>> Make sense? Have we missing a potential GIT behaviour doing it this
>>>> way?
>>>>>>>
>>>>>>>
>>>>>>> Pierre-Luc Dion
>>>>>>> Architecte de Solution Cloud | Cloud Solutions Architect
>>>>>>> 855-OK-CLOUD (855-652-5683) x1101
>>>>>>> - - -
>>>>>>>
>>>>>>> *CloudOps*420 rue Guy
>>>>>>> Montréal QC H3J 1S6
>>>>>>> www.cloudops.com
>>>>>>> @CloudOps_
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Daan
>>>>>
>>>>
>>
Re: release note documentation
Posted by David Nalley <da...@gnsa.us>.
Are you shipping (e.g. making source available for download) tarballs
or merely producing documentation that we publish publicly.
If the answer to that is no; then we don't need votes or a formal
release process (anymore than we need votes for publishing content to
cloudstack.apache.org
--David
On Thu, Apr 17, 2014 at 11:43 AM, sebgoa <ru...@gmail.com> wrote:
>
> On Apr 17, 2014, at 5:31 PM, Pierre-Luc Dion <pd...@cloudops.com> wrote:
>
>> Should we have a page on wiki explaining how we would handle release-notes
>> on RTD ? and then vote on the method?
>> I'm not seeing other alternative to branches exept having one RTD project
>> for each release-notes.
>>
>
> I think your email here explains it well.
>
> What we need now is a [DISCUSS] thread on whether we want to vote on docs releases and whether we need a formal release process or not ?
>
> Do you want to start that thread ;)
>
>>
>>
>>
>>
>> Pierre-Luc Dion
>> Architecte de Solution Cloud | Cloud Solutions Architect
>> 855-OK-CLOUD (855-652-5683) x1101
>> - - -
>>
>> *CloudOps*420 rue Guy
>> Montréal QC H3J 1S6
>> www.cloudops.com
>> @CloudOps_
>>
>>
>> On Tue, Apr 15, 2014 at 12:28 PM, David Nalley <da...@gnsa.us> wrote:
>>
>>> So I think it makes sense for most documents to point to feature
>>> version (e.g. 4.3 branch, 4.4 branch.) E.g. docs for 4.3.1 should be
>>> materially the same as 4.3.0 from a docs standpoint. Release notes are
>>> the exception here, though perhaps they could be dealt with in an
>>> additive way.
>>>
>>> --David
>>>
>>> On Tue, Apr 15, 2014 at 11:17 AM, sebgoa <ru...@gmail.com> wrote:
>>>> To add to what Pierre-Luc said:
>>>>
>>>> Readthedocs has something they call "releases" but those are in fact
>>> builds that point to a branch. Not a specific tag.
>>>>
>>>> So the release version of the doc we would see on the website will be
>>> the live state of the release branch, not a tag that we could vote on.
>>>>
>>>> That said, we have not yet discussed whether or not we need to formally
>>> vote on doc releases :)
>>>>
>>>> -sebastien
>>>>
>>>>
>>>> On Apr 15, 2014, at 3:56 PM, Daan Hoogland <da...@gmail.com>
>>> wrote:
>>>>
>>>>> makes sense! the only behavior that needs to be taken into account is
>>>>> that of any publication scripts that we might write. So it seems to me
>>>>> this is the best result we have from this version of the hackathon :(
>>>>> & :)
>>>>>
>>>>> On Tue, Apr 15, 2014 at 2:54 PM, Pierre-Luc Dion <pd...@cloudops.com>
>>> wrote:
>>>>>> At the hackathon of CCCNA14 with Sebastien, we made few tests the RTD
>>> for
>>>>>> documentation versioning.
>>>>>>
>>>>>> Look like we can use branch instead of tag for versioning and we can
>>> also
>>>>>> select which branches are published on RTD.org
>>>>>>
>>>>>> So, in order to have doc version match product version, would it make
>>> sense
>>>>>> to create a branch call 4.3.0 for the current CS version and start
>>> updating
>>>>>> master for next version 4.4 ? once we will have 4.4 pretty much ready
>>> we
>>>>>> will be able to create new branch 4.4.
>>>>>>
>>>>>> By using branches it allow us to update documentation without having to
>>>>>> update is version.
>>>>>>
>>>>>> Make sense? Have we missing a potential GIT behaviour doing it this
>>> way?
>>>>>>
>>>>>>
>>>>>> Pierre-Luc Dion
>>>>>> Architecte de Solution Cloud | Cloud Solutions Architect
>>>>>> 855-OK-CLOUD (855-652-5683) x1101
>>>>>> - - -
>>>>>>
>>>>>> *CloudOps*420 rue Guy
>>>>>> Montréal QC H3J 1S6
>>>>>> www.cloudops.com
>>>>>> @CloudOps_
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Daan
>>>>
>>>
>
Re: release note documentation
Posted by sebgoa <ru...@gmail.com>.
On Apr 17, 2014, at 5:31 PM, Pierre-Luc Dion <pd...@cloudops.com> wrote:
> Should we have a page on wiki explaining how we would handle release-notes
> on RTD ? and then vote on the method?
> I'm not seeing other alternative to branches exept having one RTD project
> for each release-notes.
>
I think your email here explains it well.
What we need now is a [DISCUSS] thread on whether we want to vote on docs releases and whether we need a formal release process or not ?
Do you want to start that thread ;)
>
>
>
>
> Pierre-Luc Dion
> Architecte de Solution Cloud | Cloud Solutions Architect
> 855-OK-CLOUD (855-652-5683) x1101
> - - -
>
> *CloudOps*420 rue Guy
> Montréal QC H3J 1S6
> www.cloudops.com
> @CloudOps_
>
>
> On Tue, Apr 15, 2014 at 12:28 PM, David Nalley <da...@gnsa.us> wrote:
>
>> So I think it makes sense for most documents to point to feature
>> version (e.g. 4.3 branch, 4.4 branch.) E.g. docs for 4.3.1 should be
>> materially the same as 4.3.0 from a docs standpoint. Release notes are
>> the exception here, though perhaps they could be dealt with in an
>> additive way.
>>
>> --David
>>
>> On Tue, Apr 15, 2014 at 11:17 AM, sebgoa <ru...@gmail.com> wrote:
>>> To add to what Pierre-Luc said:
>>>
>>> Readthedocs has something they call "releases" but those are in fact
>> builds that point to a branch. Not a specific tag.
>>>
>>> So the release version of the doc we would see on the website will be
>> the live state of the release branch, not a tag that we could vote on.
>>>
>>> That said, we have not yet discussed whether or not we need to formally
>> vote on doc releases :)
>>>
>>> -sebastien
>>>
>>>
>>> On Apr 15, 2014, at 3:56 PM, Daan Hoogland <da...@gmail.com>
>> wrote:
>>>
>>>> makes sense! the only behavior that needs to be taken into account is
>>>> that of any publication scripts that we might write. So it seems to me
>>>> this is the best result we have from this version of the hackathon :(
>>>> & :)
>>>>
>>>> On Tue, Apr 15, 2014 at 2:54 PM, Pierre-Luc Dion <pd...@cloudops.com>
>> wrote:
>>>>> At the hackathon of CCCNA14 with Sebastien, we made few tests the RTD
>> for
>>>>> documentation versioning.
>>>>>
>>>>> Look like we can use branch instead of tag for versioning and we can
>> also
>>>>> select which branches are published on RTD.org
>>>>>
>>>>> So, in order to have doc version match product version, would it make
>> sense
>>>>> to create a branch call 4.3.0 for the current CS version and start
>> updating
>>>>> master for next version 4.4 ? once we will have 4.4 pretty much ready
>> we
>>>>> will be able to create new branch 4.4.
>>>>>
>>>>> By using branches it allow us to update documentation without having to
>>>>> update is version.
>>>>>
>>>>> Make sense? Have we missing a potential GIT behaviour doing it this
>> way?
>>>>>
>>>>>
>>>>> Pierre-Luc Dion
>>>>> Architecte de Solution Cloud | Cloud Solutions Architect
>>>>> 855-OK-CLOUD (855-652-5683) x1101
>>>>> - - -
>>>>>
>>>>> *CloudOps*420 rue Guy
>>>>> Montréal QC H3J 1S6
>>>>> www.cloudops.com
>>>>> @CloudOps_
>>>>
>>>>
>>>>
>>>> --
>>>> Daan
>>>
>>
Re: release note documentation
Posted by Pierre-Luc Dion <pd...@cloudops.com>.
Should we have a page on wiki explaining how we would handle release-notes
on RTD ? and then vote on the method?
I'm not seeing other alternative to branches exept having one RTD project
for each release-notes.
Pierre-Luc Dion
Architecte de Solution Cloud | Cloud Solutions Architect
855-OK-CLOUD (855-652-5683) x1101
- - -
*CloudOps*420 rue Guy
Montréal QC H3J 1S6
www.cloudops.com
@CloudOps_
On Tue, Apr 15, 2014 at 12:28 PM, David Nalley <da...@gnsa.us> wrote:
> So I think it makes sense for most documents to point to feature
> version (e.g. 4.3 branch, 4.4 branch.) E.g. docs for 4.3.1 should be
> materially the same as 4.3.0 from a docs standpoint. Release notes are
> the exception here, though perhaps they could be dealt with in an
> additive way.
>
> --David
>
> On Tue, Apr 15, 2014 at 11:17 AM, sebgoa <ru...@gmail.com> wrote:
> > To add to what Pierre-Luc said:
> >
> > Readthedocs has something they call "releases" but those are in fact
> builds that point to a branch. Not a specific tag.
> >
> > So the release version of the doc we would see on the website will be
> the live state of the release branch, not a tag that we could vote on.
> >
> > That said, we have not yet discussed whether or not we need to formally
> vote on doc releases :)
> >
> > -sebastien
> >
> >
> > On Apr 15, 2014, at 3:56 PM, Daan Hoogland <da...@gmail.com>
> wrote:
> >
> >> makes sense! the only behavior that needs to be taken into account is
> >> that of any publication scripts that we might write. So it seems to me
> >> this is the best result we have from this version of the hackathon :(
> >> & :)
> >>
> >> On Tue, Apr 15, 2014 at 2:54 PM, Pierre-Luc Dion <pd...@cloudops.com>
> wrote:
> >>> At the hackathon of CCCNA14 with Sebastien, we made few tests the RTD
> for
> >>> documentation versioning.
> >>>
> >>> Look like we can use branch instead of tag for versioning and we can
> also
> >>> select which branches are published on RTD.org
> >>>
> >>> So, in order to have doc version match product version, would it make
> sense
> >>> to create a branch call 4.3.0 for the current CS version and start
> updating
> >>> master for next version 4.4 ? once we will have 4.4 pretty much ready
> we
> >>> will be able to create new branch 4.4.
> >>>
> >>> By using branches it allow us to update documentation without having to
> >>> update is version.
> >>>
> >>> Make sense? Have we missing a potential GIT behaviour doing it this
> way?
> >>>
> >>>
> >>> Pierre-Luc Dion
> >>> Architecte de Solution Cloud | Cloud Solutions Architect
> >>> 855-OK-CLOUD (855-652-5683) x1101
> >>> - - -
> >>>
> >>> *CloudOps*420 rue Guy
> >>> Montréal QC H3J 1S6
> >>> www.cloudops.com
> >>> @CloudOps_
> >>
> >>
> >>
> >> --
> >> Daan
> >
>
Re: release note documentation
Posted by David Nalley <da...@gnsa.us>.
So I think it makes sense for most documents to point to feature
version (e.g. 4.3 branch, 4.4 branch.) E.g. docs for 4.3.1 should be
materially the same as 4.3.0 from a docs standpoint. Release notes are
the exception here, though perhaps they could be dealt with in an
additive way.
--David
On Tue, Apr 15, 2014 at 11:17 AM, sebgoa <ru...@gmail.com> wrote:
> To add to what Pierre-Luc said:
>
> Readthedocs has something they call "releases" but those are in fact builds that point to a branch. Not a specific tag.
>
> So the release version of the doc we would see on the website will be the live state of the release branch, not a tag that we could vote on.
>
> That said, we have not yet discussed whether or not we need to formally vote on doc releases :)
>
> -sebastien
>
>
> On Apr 15, 2014, at 3:56 PM, Daan Hoogland <da...@gmail.com> wrote:
>
>> makes sense! the only behavior that needs to be taken into account is
>> that of any publication scripts that we might write. So it seems to me
>> this is the best result we have from this version of the hackathon :(
>> & :)
>>
>> On Tue, Apr 15, 2014 at 2:54 PM, Pierre-Luc Dion <pd...@cloudops.com> wrote:
>>> At the hackathon of CCCNA14 with Sebastien, we made few tests the RTD for
>>> documentation versioning.
>>>
>>> Look like we can use branch instead of tag for versioning and we can also
>>> select which branches are published on RTD.org
>>>
>>> So, in order to have doc version match product version, would it make sense
>>> to create a branch call 4.3.0 for the current CS version and start updating
>>> master for next version 4.4 ? once we will have 4.4 pretty much ready we
>>> will be able to create new branch 4.4.
>>>
>>> By using branches it allow us to update documentation without having to
>>> update is version.
>>>
>>> Make sense? Have we missing a potential GIT behaviour doing it this way?
>>>
>>>
>>> Pierre-Luc Dion
>>> Architecte de Solution Cloud | Cloud Solutions Architect
>>> 855-OK-CLOUD (855-652-5683) x1101
>>> - - -
>>>
>>> *CloudOps*420 rue Guy
>>> Montréal QC H3J 1S6
>>> www.cloudops.com
>>> @CloudOps_
>>
>>
>>
>> --
>> Daan
>
Re: release note documentation
Posted by sebgoa <ru...@gmail.com>.
To add to what Pierre-Luc said:
Readthedocs has something they call "releases" but those are in fact builds that point to a branch. Not a specific tag.
So the release version of the doc we would see on the website will be the live state of the release branch, not a tag that we could vote on.
That said, we have not yet discussed whether or not we need to formally vote on doc releases :)
-sebastien
On Apr 15, 2014, at 3:56 PM, Daan Hoogland <da...@gmail.com> wrote:
> makes sense! the only behavior that needs to be taken into account is
> that of any publication scripts that we might write. So it seems to me
> this is the best result we have from this version of the hackathon :(
> & :)
>
> On Tue, Apr 15, 2014 at 2:54 PM, Pierre-Luc Dion <pd...@cloudops.com> wrote:
>> At the hackathon of CCCNA14 with Sebastien, we made few tests the RTD for
>> documentation versioning.
>>
>> Look like we can use branch instead of tag for versioning and we can also
>> select which branches are published on RTD.org
>>
>> So, in order to have doc version match product version, would it make sense
>> to create a branch call 4.3.0 for the current CS version and start updating
>> master for next version 4.4 ? once we will have 4.4 pretty much ready we
>> will be able to create new branch 4.4.
>>
>> By using branches it allow us to update documentation without having to
>> update is version.
>>
>> Make sense? Have we missing a potential GIT behaviour doing it this way?
>>
>>
>> Pierre-Luc Dion
>> Architecte de Solution Cloud | Cloud Solutions Architect
>> 855-OK-CLOUD (855-652-5683) x1101
>> - - -
>>
>> *CloudOps*420 rue Guy
>> Montréal QC H3J 1S6
>> www.cloudops.com
>> @CloudOps_
>
>
>
> --
> Daan
Re: release note documentation
Posted by Daan Hoogland <da...@gmail.com>.
makes sense! the only behavior that needs to be taken into account is
that of any publication scripts that we might write. So it seems to me
this is the best result we have from this version of the hackathon :(
& :)
On Tue, Apr 15, 2014 at 2:54 PM, Pierre-Luc Dion <pd...@cloudops.com> wrote:
> At the hackathon of CCCNA14 with Sebastien, we made few tests the RTD for
> documentation versioning.
>
> Look like we can use branch instead of tag for versioning and we can also
> select which branches are published on RTD.org
>
> So, in order to have doc version match product version, would it make sense
> to create a branch call 4.3.0 for the current CS version and start updating
> master for next version 4.4 ? once we will have 4.4 pretty much ready we
> will be able to create new branch 4.4.
>
> By using branches it allow us to update documentation without having to
> update is version.
>
> Make sense? Have we missing a potential GIT behaviour doing it this way?
>
>
> Pierre-Luc Dion
> Architecte de Solution Cloud | Cloud Solutions Architect
> 855-OK-CLOUD (855-652-5683) x1101
> - - -
>
> *CloudOps*420 rue Guy
> Montréal QC H3J 1S6
> www.cloudops.com
> @CloudOps_
--
Daan