version change

[zdenko podobny]

I saw several projects that after publishing new release they change version information as soon as possible. We already discussed that there should be 3.04.01 bugfix release (at least with opencl fixes), so there should not be problem to change version in current code.

But maybe it would be better to handle it with branches - e.g. to crease special branch 3.04 for bugfix releases and to use master branch (version info could be 3.05.dev?) for integrating and testing new features (e.g. tsv[1])?

Zdenko

[1] https://github.com/tesseract-ocr/tesseract/pull/18

[Jim O'Regan]

On 20 July 2015 at 07:44, zdenko podobny <zde...@gmail.com> wrote:
> I saw several projects that after publishing new release they change version
> information as soon as possible. We already discussed that there should be
> 3.04.01 bugfix release (at least with opencl fixes), so there should not be
> problem to change version in current code.
>
> But maybe it would be better to handle it with branches - e.g. to crease
> special branch 3.04 for bugfix releases and to use master branch (version
> info could be 3.05.dev?) for integrating and testing new features (e.g.
> tsv[1])?

Sure, that makes sense.

--
<Sefam> Are any of the mentors around?
<jimregan> yes, they're the ones trolling you

[Tom Morris]

On Mon, Jul 20, 2015 at 2:44 AM, zdenko podobny <zde...@gmail.com> wrote:

I saw several projects that after publishing new release they change version information as soon as possible. We already discussed that there should be 3.04.01 bugfix release (at least with opencl fixes), so there should not be problem to change version in current code.

But maybe it would be better to handle it with branches - e.g. to crease special branch 3.04 for bugfix releases and to use master branch (version info could be 3.05.dev?) for integrating and testing new features (e.g. tsv[1])?

I think implementing both the version change and the branches is a good idea.  Presumably the branch would be called something like 3.04 or 3.04.xx and the interim version would have an identifiable suffix such as 3.04.01-dev until release to distinguish it from the actual release.

This adds a little extra work in backporting bug fixes, but git is low enough overhead that it's not a big deal and the separate branches keep everything much cleaner.

Tom

[ShreeDevi Kumar]

I would think that 3.05.dev should also be a separate branch.

See https://www.atlassian.com/git/tutorials/comparing-workflows/forking-workflow for a good visual explanation with master, develop, hotfix branches etc.

It maybe good to choose and follow one of these workflows for future development  of tesseract.

- sent from my phone. excuse the brevity

--
You received this message because you are subscribed to the Google Groups "tesseract-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tesseract-de...@googlegroups.com.
To post to this group, send email to tesser...@googlegroups.com.
Visit this group at http://groups.google.com/group/tesseract-dev.
To view this discussion on the web visit https://groups.google.com/d/msgid/tesseract-dev/CAE9vqEFw%3DQLXHmeB-8Fu2%2BAH-4SpVT57LXaHhzMqehfmWKzncA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[ShreeDevi Kumar]

https://www.atlassian.com/git/images/tutorials/collaborating/comparing-workflows/gitflow-workflow/05.svg

- sent from my phone. excuse the brevity

[Jim O'Regan]

On 21 July 2015 at 11:51, ShreeDevi Kumar <shree...@gmail.com> wrote:
> I would think that 3.05.dev should also be a separate branch.
>

The workflow should serve the development model, not the other way around.

If there were several people working regularly on various pieces, then
some sort of hierarchical scheme for integration would be necessary.
There aren't, so it's not. For Tesseract's relatively modest needs,
that would just be git for git's sake.

The main advantage of using master as the dev branch is that it'll get
tested. If you think that would still happen on another branch, I
encourage you to go count the number of comments on the existing pull
requests.

[Jim O'Regan]

On 21 July 2015 at 12:34, Jim O'Regan <jor...@gmail.com> wrote:
> On 21 July 2015 at 11:51, ShreeDevi Kumar <shree...@gmail.com> wrote:
>> I would think that 3.05.dev should also be a separate branch.
>>
>
> The workflow should serve the development model, not the other way around.
>
> If there were several people working regularly on various pieces, then
> some sort of hierarchical scheme for integration would be necessary.
> There aren't, so it's not. For Tesseract's relatively modest needs,
> that would just be git for git's sake.
>
> The main advantage of using master as the dev branch is that it'll get
> tested. If you think that would still happen on another branch, I
> encourage you to go count the number of comments on the existing pull
> requests.

All that said, what would make sense would be to have a 'release'
branch, to make releases from. And put the generated files there only,
because they're getting to be really irritating.

[zdenko podobny]

OK.

I created branch 3.04 increase there version number to 3.04.01dev and tagged it (because in debug release version number is took from git tags.

Also in master I increased version number to 3.05.00dev and tagged it, so new features and enhancement could be committed there.

Zdenko

--
You received this message because you are subscribed to the Google Groups "tesseract-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tesseract-de...@googlegroups.com.
To post to this group, send email to tesser...@googlegroups.com.
Visit this group at http://groups.google.com/group/tesseract-dev.

To view this discussion on the web visit https://groups.google.com/d/msgid/tesseract-dev/CAHh9-xtg7fBWNq4s7sPUhFm-hL6UFEJYyFu6DaR7O04mnLGKFw%40mail.gmail.com.