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: release 1.8.1
Date Mon, 11 Jun 2012 22:22:48 GMT
>
> Hmm.. Can we have multiple tags in git pointing to the same commit? This
> way we COULD tag all platforms, but non-ios platforms' 1.8.1 just points
> to the same commit as 1.8.0.


Yes, a tag is just a reference to a SHA. However, we still need to update
the VERSION file for each platform.

All platforms but iOS should be able to branch off 1.8.0, update the code,
and merge it back:

- `git checkout -b 1.8.0 new-release`
- update the version to 1.8.1
- `git commit -am "Version 1.8.1"
- `git tag 1.8.1`
- `git checkout master`
- `git merge new-release`
- `git branch -d new-release`
- `git push origin`

Am I missing something?

On Mon, Jun 11, 2012 at 2:44 PM, Filip Maj <fil@adobe.com> wrote:

> Hmm.. Can we have multiple tags in git pointing to the same commit? This
> way we COULD tag all platforms, but non-ios platforms' 1.8.1 just points
> to the same commit as 1.8.0.
>
> On 6/11/12 2:41 PM, "Jesse" <purplecabbage@gmail.com> wrote:
>
> >I still think we should serve the new updated+package distribution, just
> >not modify platforms that do not have changes.
> >Call it a hotfix ...
> >
> >On Mon, Jun 11, 2012 at 2:38 PM, Filip Maj <fil@adobe.com> wrote:
> >
> >> The thing is that the downstream distribution of cordova (phonegap) gets
> >> *a lot* of exposure/downloads via a single archive containing all
> >>platform
> >> implementations.
> >>
> >> Tagging a 1.8.1 or 1.8.0.1 on a single platform and blogging about it
> >> would probably work for the (small) user base that is involved on the
> >> issue tracker+mailing list, and is comfortable with git, etc. However
> >>for
> >> the vast majority of users these are all "hoops" they have to go through
> >> and, in light of a latest point release crashing for them already,
> >> probably would just add to their frustration.
> >>
> >> If we want to be up front and honest about the issue and how to fix it,
> >>as
> >> well as provide as simple a solution to people who may have fallen into
> >> the issue in the first place, I am of the opinion we should tag 1.8.1
> >> across the board, blog about it _AND_ host up another dist.
> >>
> >> Would love to hear what non-Adobe folks have to say about this.
> >>
> >> On 6/11/12 2:30 PM, "Jesse" <purplecabbage@gmail.com> wrote:
> >>
> >> >Before I tip my hand on a vote ...
> >> >Is there any chance of a middle ground here?
> >> >Updating all platforms to 1.8.1 for the benefit of one platform seems
> >>like
> >> >a lot of overhead to address a change in one.
> >> >
> >> >Could we adopt packaging a 1.8.0.1.zip which would include the updated
> >>iOS
> >> >code, and iOS code tags, but no changes to the other platforms? or
> >> >something similar?
> >> >
> >> >Of course this would require adding a little documentation to the
> >>release,
> >> >to say what was addressed, and what platforms were changed, but still
> >> >considerably easier than the tag->domino effect we have now. IMO
> >> >
> >> >On Mon, Jun 11, 2012 at 2:18 PM, Filip Maj <fil@adobe.com> wrote:
> >> >
> >> >> +1 release 1.8.1
> >> >>
> >> >> On 6/11/12 2:15 PM, "Brian LeRoux" <b@brian.io> wrote:
> >> >>
> >> >> >So we have a fairly big issue in iOS 1.8 wherein a PhoneGap app
is
> >> >> >crashing if the user swipes down the notification centre while
> >>in-app.
> >> >> >The question is whether this is a bug big enough to cut an 1.8.1
> >> >> >official release for all platforms or if pointing users to the
minor
> >> >> >tag is enough.
> >> >> >
> >> >> >[+1] release 1.8.1
> >> >> >[ -1] do not release 1.8.1
> >> >> >
> >> >> >I think a tag should suffice but if implementors have no trouble
> >> >> >tagging a release then we might as well save Shaz/Becky the
> >> >> >email/twitter complaint!
> >> >>
> >> >>
> >> >
> >> >
> >> >--
> >> >@purplecabbage
> >> >risingj.com
> >>
> >>
> >
> >
> >--
> >@purplecabbage
> >risingj.com
>
>

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