incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Brooks <mich...@michaelbrooks.ca>
Subject Re: Lower-overhead release process
Date Fri, 21 Sep 2012 00:23:51 GMT
On my first read, I thought Jukka was suggesting that each platform should
develop on its own track. For example, Android may be at tag 4.0.3, iOS at
3.1.2, etc. Then at release time, we would cut a "2.2.0" from each of their
latest tags. However, I totally misunderstood.

When looking at the current 2.1.0 release candidate my first
> impression is that there's no build script and the only instructions
> on how to build this thing is to "change directories to the platform
> that you wish to build for and read the README file." And to get to
> those platform sources I first need to unpack them to a separate
> directory.


I agree that the release packaging and building can be cleaned up. Like
many components of this project, it will continue to improve on each
iteration. The notion of cutting a source release is new to most of the
Apache Cordova team and hopefully we'll streamline it a little more on each
release.

The underlying issue is that this project has a lot of shared resources.


Fil has nailed the main issue. Each platform release is dependent on a few
shared projects. If any of the platforms encounter a bug that must be fixed
in the shared resource, then the platform release must be restarted. CI is
a big factor is helping to reduce the chance of a release-restart.

$ cd incubator-cordova-android
> $ cordova-release.sh 2.2.0


I do like this suggestion, although the signed git tag may be too big of a
leap to start off with. I'm not suggesting that we adopt the script, but
it's worth thinking about in the context of our coho release tool. The idea
is that a source release is blind to the platform and simply cuts the
source release from a given tag (perhaps running an audit for common
oversights).

Michael

On Thu, Sep 20, 2012 at 11:57 AM, Filip Maj <fil@adobe.com> wrote:

> Talking with Anis, CI would solve this problem..
>
> On 9/20/12 11:53 AM, "Filip Maj" <fil@adobe.com> wrote:
>
> >I agree with Joe in that the specific, automated steps to create a
> >sub-project's release won't help in streamlining the release process for
> >this project. Appreciate your efforts to help in this regard though,
> >Jukka.
> >
> >The underlying issue is that this project has a lot of shared resources.
> >The javascript, example "hello world" app and the test suite are
> >standalone projects but are used by all platform implementations. The crux
> >of the slow release process is this: the shared projects need to be tagged
> >before the platform implementations can be. If we find a problem in the
> >shared projects, then all platforms need a retagging.
> >
> >If the above problem can be solved, then the release flow will improve.
> >
> >Perhaps this is more a matter of diligence and testing than a problem with
> >the release steps themselves. If we are better at catching issues with
> >shared sub-projects on all platforms, then the retag cycle (ideally) would
> >be eliminated.
> >
> >Either way, there is ceremony and process involved. A lot of testing. Many
> >devices. Lots of platforms. Communication and a bit of planning can help
> >here. A week before a potential tag we could create an issue to track
> >progress of testing JS+test suite+hello world sub-projects across all
> >platforms. Only once all of those tasks are done can we with confidence
> >say that the shared projects are stable and we can copy them into the
> >platform implementations that we ship and tag those.
> >
> >Thoughts?
> >
> >On 9/20/12 11:32 AM, "Jukka Zitting" <jukka.zitting@gmail.com> wrote:
> >
> >>Hi,
> >>
> >>On Thu, Sep 20, 2012 at 6:45 PM, Joe Bowser <bowserj@gmail.com> wrote:
> >>> I know, I'm just saying that this has the same effect as releasing the
> >>> components independently.  I'm not convinced that this would reduce
> >>> overhead when it comes to releases.
> >>
> >>OK, fair enough.
> >>
> >>> Also, how would this make us conform to the Apache requirements
> >>> better?
> >>
> >>Not strict requirements as such (the current release package is IMHO
> >>fine from a policy perspective), but rather a more pragmatic point of
> >>view that underlies the Apache policies.
> >>
> >>The release guide [1] speaks of releases being "in the form of the
> >>source materials needed to make changes to the software", which in
> >>practice means that it's a good idea for the structure of the release
> >>to be as close as possible to the structure of the source in the
> >>version control system. The purpose of cutting a source release is not
> >>to satisfy an abstract policy but rather to produce something that
> >>downstream developers can easily use and modify to best match their
> >>needs.
> >>
> >>When looking at the current 2.1.0 release candidate my first
> >>impression is that there's no build script and the only instructions
> >>on how to build this thing is to "change directories to the platform
> >>that you wish to build for and read the README file." And to get to
> >>those platform sources I first need to unpack them to a separate
> >>directory. I might be wrong, but it seems to me that most people would
> >>rather simply start from a tag of a relevant platfrom repository
> >>instead of building the release candidate. If that assumption is
> >>correct, then I think it would be a good idea for the release
> >>structure to better match the expected access patterns.
> >>
> >>The main point I'm trying to address here is the grumbling I see about
> >>the whole release process and its inefficiency. If the outcome of the
> >>release process isn't something that's useful, then we're doing
> >>something wrong and should fix that. If the process itself is too
> >>complicated or otherwise takes too long, we should fix that too. I'd
> >>love to hear also other ideas on how that could be done.
> >>
> >>[1] http://www.apache.org/dev/release.html#what
> >>
> >>BR,
> >>
> >>Jukka Zitting
> >
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message