Re: GNOME Shell integration for Chrome

On Sun, 2016-03-06 at 15:35 +0300, Yuri Konotopov wrote:
Hi all,

Recently I moved project repository to GNOME infrastructure
I looked through wiki learning GNOME development process, created
project wiki page
( and
I need help with next steps.

Looks cool.

1. Releasing source tarball.
  It seems I'm late with GNOME 3.20 and should target next 3.22
version.Does it mean that I can not release source tarball at GNOME
infrastructure before next unstable release?
There is feature proposal period opened for 3.22 so should I propose
module for inclusion in GNOME? How is this process looks like?

No, not at all. You don't have to follow the GNOME release cycle; in
fact, it probably makes more sense for you to follow the Chrome release
cycle if your extension will break more frequently due to Chrome
changes than due to GNOME changes, or just release whenever you think a
release is needed. The GNOME release schedule is good for most of our
modules, but it's not a perfect fit for every one.

So, you can release a source tarball whenever you want, if you
requested ftp access for your GNOME account when the accounts team
created it. If you don't have that access yet, request it from <account
s gnome org>. Once you get access, follow these instructions:

And ping me or one of the other release team members on IRC if you run
into trouble making your first release.

The new feature proposal period is archaic and mostly unused, so don't
worry about that either.

2. Release process for Chrome Web Store.
  GNOME Shell integration for Chrome consists of 2 parts:
 1) Web extension hosted at Chrome Store:
 2) Native host messaging program written in python.

Currently, web extension released at Chrome Store under my account.
Should I transfer extension ownership to some Release Team account? I
don't think there is one exists so will Release Team create such

I would say, for the time being, you should just keep it under your own

But that is not ideal; we should really set up some private wiki page
with passwords for external services, and then give you the password
for the Chrome account so that you can manage it under a GNOME-branded
account, but anyone from release team could take over if you disappear.

We have a similar problem with Google Play.

3. Project version.
Early I incremented major project version every release so 5 versions
product already exists.
I can not lower version of extension at Chrome web store to match
version. However it's possible to release new extension under new id
replace old extension with some "dumb" extension containing move
Other ways - keep current versioning or move to something like
"year.gnome_release", for example: 2016.3.22 for feature GNOME
What do you think about this problem?

Just keep using your own versioning scheme, though distributors might
get confused and wonder if odd major versions are unstable, so you
should probably clarify that in the README. I guess you don't currently
do unstable releases and that all releases should go into distros,
which should be mentioned in the README.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]