Re: Versioning for Mozbase modules

[David Burns]

Looking at the wiki I am not sure what you would do if you need to
release multiple items. e.g. Mozrunner and Mozprofile at the same time.
Are you going to do a number of tags at the same time?

David

On 19/04/2012 19:12, Henrik Skupin wrote:
> Hi all,
>
> Given that more and more tools will rely on Mozbase and sometimes on a
> specific version of contained modules, we should have a versioning
> schema for it.
>
> Clint, Jeff, and me discussed this a couple of minutes ago based on the
> Mozmill project and we would like to propose the the following guideline:
>
> https://wiki.mozilla.org/Auto-tools/Projects/MozBase#Versioning
>
> We kinda would like to get your feedback on it.
>
> Cheers,
>


--
David Burns
Email: dbu...@mozilla.com
Twitter: automatedtester

[David Burns]

[Henrik Skupin]

David Burns wrote on 4/19/12 11:21 AM:

> Looking at the wiki I am not sure what you would do if you need to
> release multiple items. e.g. Mozrunner and Mozprofile at the same time.
> Are you going to do a number of tags at the same time?

That's exactly what the wiki page tells you. Add multiple tags for the
same changeset.

--
Henrik Skupin
Software Engineer in Test
Mozilla Corporation

[David Burns]

That might be very confusing if you want to see a snapshot of a version
of something. The changeset might not be really intuitive to spot. E.g.
https://github.com/AutomatedTester/github-travis-addon/tags

It might be better then to split Mozbase into separate projects to allow
easier use since getting a tag out will be a lot easier and a lot more
intuitive.

David

On 19/04/2012 19:23, Henrik Skupin wrote:
> David Burns wrote on 4/19/12 11:21 AM:
>> Looking at the wiki I am not sure what you would do if you need to
>> release multiple items. e.g. Mozrunner and Mozprofile at the same time.
>> Are you going to do a number of tags at the same time?
> That's exactly what the wiki page tells you. Add multiple tags for the
> same changeset.
>


--

[William Lachance]

On 04/19/2012 11:40 AM, David Burns wrote:
> That might be very confusing if you want to see a snapshot of a version
> of something. The changeset might not be really intuitive to spot. E.g.
> https://github.com/AutomatedTester/github-travis-addon/tags
>
> It might be better then to split Mozbase into separate projects to allow
> easier use since getting a tag out will be a lot easier and a lot more
> intuitive.

This has come up a few times (e.g.
https://groups.google.com/forum/#!topic/mozilla.tools/kXxOmaJWO_A/discussion).


I think the short answer is that you are probably right, but keeping
things together has a few advantages:

* When you want to hack on mozbase, you only need to check out one
repository.
* Many mozbase modules depend on one another (for example, mozrunner
consumes mozprocess and mozprofile). Sometimes you want to make changes
to multiple modules at the same time, and it's easier to do this with a
single commit/issue.

I honestly don't feel that strongly one way or another about this issue
(both ways have their pros&cons), but IMO the path of least resistance
weighs in favour of leaving things as they are.

Will

[Jeff Hammel]

FWIW, although I would favor in theory breaking up the repository, I
agree with Will that it is just easier to leave things the way they are
for now, or at least I don't have the time to change things right now.
If we did break it apart, we would want a glue script for
setup_development to download all the modules and set them up in
development with correct dependency order preserved. I'm also planning
on making the setup_development script do version bumping since much of
the logic is already there.

I think we should continue with what we have for now and do some version
bumping and if things start to look rough going forward we can
reconsider our strategy here.

Jeff

On 04/19/2012 01:45 PM, William Lachance wrote:
> On 04/19/2012 11:40 AM, David Burns wrote:

>> That might be very confusing if you want to see a snapshot of a version
>> of something. The changeset might not be really intuitive to spot. E.g.
>> https://github.com/AutomatedTester/github-travis-addon/tags
>>
>> It might be better then to split Mozbase into separate projects to allow
>> easier use since getting a tag out will be a lot easier and a lot more
>> intuitive.
>

> This has come up a few times (e.g.
> https://groups.google.com/forum/#!topic/mozilla.tools/kXxOmaJWO_A/discussion).
>
>
> I think the short answer is that you are probably right, but keeping
> things together has a few advantages:
>
> * When you want to hack on mozbase, you only need to check out one
> repository.
> * Many mozbase modules depend on one another (for example, mozrunner
> consumes mozprocess and mozprofile). Sometimes you want to make
> changes to multiple modules at the same time, and it's easier to do
> this with a single commit/issue.
>
> I honestly don't feel that strongly one way or another about this
> issue (both ways have their pros&cons), but IMO the path of least
> resistance weighs in favour of leaving things as they are.
>
> Will

> _______________________________________________
> tools mailing list
> to...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/tools

[Henrik Skupin]

Jeff Hammel wrote on 4/19/12 11:10 PM:

> FWIW, although I would favor in theory breaking up the repository, I
> agree with Will that it is just easier to leave things the way they are
> for now, or at least I don't have the time to change things right now.
> If we did break it apart, we would want a glue script for
> setup_development to download all the modules and set them up in
> development with correct dependency order preserved. I'm also planning
> on making the setup_development script do version bumping since much of
> the logic is already there.

If we would go with separate projects there would even be a simpler
solution. Instead of a glue script as you mentioned above we make the
mozbase repository the god of everything by including all other modules
as submodules, e.g. mozInstall, mozhttpd,... So each of those can live
in its own repository.

That means a developer would only have to check out mozbase. Submodules
will be initialized and updated automatically. setup_development.py will
be part of mozbase and wouldn't require a change because the repository
will look the same.

We make use of it for MemChaser which gets build on top of the Add-on SDK:
https://github.com/mozilla/memchaser

See the link to 'addon-sdk @ de78ccb' which references the submodule and
the tagged version. In case of mozbase it will probably always be master.

To prepare mozbase for development you would have to do:

git clone g...@github.com:mozilla/mozbase.git
cd mozbase
git submodule update --init

With the last command all referenced sub modules will be cloned or updated.

Could that be an option?

[William Lachance]

On 04/23/2012 04:06 PM, Henrik Skupin wrote:
> We make use of it for MemChaser which gets build on top of the Add-on SDK:
> https://github.com/mozilla/memchaser
>
> See the link to 'addon-sdk @ de78ccb' which references the submodule and
> the tagged version. In case of mozbase it will probably always be master.
>
> To prepare mozbase for development you would have to do:
>

> git clon...@github.com:mozilla/mozbase.git

> cd mozbase
> git submodule update --init
>
> With the last command all referenced sub modules will be cloned or updated.
>
> Could that be an option?

Could be an option. The main issue with submodules is that you need to
update the parent repository whenever one of the child repositories
changes, so it comes with its own complexity Branch, push, and commit
don't work exactly the way you expect if you're used to using a single
repository. I use them myself for various projects, but they're a bit of
an "expert" feature.

Will

[William Lachance]

On 04/23/2012 04:06 PM, Henrik Skupin wrote:

> We make use of it for MemChaser which gets build on top of the Add-on SDK:
> https://github.com/mozilla/memchaser
>
> See the link to 'addon-sdk @ de78ccb' which references the submodule and
> the tagged version. In case of mozbase it will probably always be master.
>
> To prepare mozbase for development you would have to do:
>

> git clon...@github.com:mozilla/mozbase.git

> cd mozbase
> git submodule update --init
>
> With the last command all referenced sub modules will be cloned or updated.
>
> Could that be an option?

[William Lachance]

On 04/23/2012 04:06 PM, Henrik Skupin wrote:

> We make use of it for MemChaser which gets build on top of the Add-on SDK:
> https://github.com/mozilla/memchaser
>
> See the link to 'addon-sdk @ de78ccb' which references the submodule and
> the tagged version. In case of mozbase it will probably always be master.
>
> To prepare mozbase for development you would have to do:
>

> git clon...@github.com:mozilla/mozbase.git

> cd mozbase
> git submodule update --init
>
> With the last command all referenced sub modules will be cloned or updated.
>
> Could that be an option?

[Henrik Skupin]

William Lachance wrote on 4/24/12 3:05 PM:

> Could be an option. The main issue with submodules is that you need to
> update the parent repository whenever one of the child repositories
> changes, so it comes with its own complexity Branch, push, and commit
> don't work exactly the way you expect if you're used to using a single
> repository. I use them myself for various projects, but they're a bit of
> an "expert" feature.

I see. I haven't noticed that yet. :(

So yes, it would require an ok from everyone involved. I for myself see
it as improvement even it's an extra push for landing stuff. But that
way we have a clean version schema.