[aerogear-dev] AGSEC components and versioning

Matthias Wessendorf matzew at apache.org
Tue Feb 10 12:04:34 EST 2015


On Tue, Feb 10, 2015 at 5:28 PM, Bruno Oliveira <bruno at abstractj.org> wrote:

> On 2015-02-10, Summers Pittman wrote:
> > On 02/10/2015 09:35 AM, Bruno Oliveira wrote:
> > > Good morning, I'm doing some housekeeping on AGSEC and would like to
> > > know what works best for you.
> > >
> > > For the further releases and for the sake of sanity at the roadmap, I'm
> > > separating the security releases by component:
> > >
> > > - Crypto
> > > - Sync
> > > - OTP
> > > - push
> > > - OAuth2
> > > - offline
> > >
> > > They are pretty much "virtual" because it project follows its own
> > > release process and I just want to group by feature. For versioning
> what
> > > would be better for you:
> > >
> > > 1. Versioning from scratch which pretty much means each component
> starts
> > >    with 0.0.1 and we increase accordingly with the progress.
> > >
> > > 2. Follow the Security roadmap versioning
> > >    (https://aerogear.org/docs/planning/roadmaps/AeroGearSecurity/).
> Which
> > >    means each component starting with 1.4.0 and increasing each one
> > >    independesing.
> > >
> > > 3. Follow each project versioning which means:
> > >    - sync: follows the same versioning for the sync server
> > >    - push: same versioning from the push server
> > >    Note: the idea would fail badly for OAuth2, Crypto and OTP
> > >
> > > I'd vote for 2 to prevent confusion.
> > Could you give examples of what each of your suggestions would look like
> > in terms of the project versions(AGIOS, AGDROID, etc) and the security
> > version(AGSEC)?  I'm not sure what the consequences of each choice are.
>
> There are no consequences to other projects, because each project
> follows its own versioning and AGSEC will always respect it.
>
> So when you read at the roadmap OAuth2 1.4, it beans a group of features
> delivered from:
>
> - AGDROID 2.0.x
> - AGIOS 1.x.x
>
> The versioning on AGSEC is pretty much to keep our sanity to have an
> idea about which features we've been planning and when, for security.
>
> Does it make sense for you?
>


yes, basically a list of epics/jiras with the (in this case) OAuth2 items,
linked to their platform specific implementation JIRAs


>
>
> > >
> > > --
> > >
> > > abstractj
> > > PGP: 0x84DC9914
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > aerogear-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> >
> > --
> > Summers Pittman
> > >>Phone:404 941 4698
> > >>Java is my crack.
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
> --
>
> abstractj
> PGP: 0x84DC9914
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20150210/81dc12ba/attachment.html 


More information about the aerogear-dev mailing list