In that case, I'd like to throw out my nomination for a class/name change...
ObjectContext (and I guess BaseContext) The words "object" and "context" don't really provide a new user or someone maintaining an app with any idea what they do. I guess I'd also add "data" to that list (such as in DataObject -- what exactly is this?). The word "base" is a bit better since it seems to imply the top-level "context" (whatever that is). I know when I was teaching new developers on Cayenne projects this naming kind of caused their eyes to glaze over for a bit. I'd mainly have to wavy-hands them and tell them "just remember you need an ObjectContext to..." Before spitballing new names, what are thoughts/feelings on this? Yes, it would be a lot of global search/replace, but probably not too much effort outside of that. (Use a shell script to automate that task in the code and docs, but the docs might need a bit more polishing.) Thanks mrg On Wed, Nov 22, 2023 at 7:18 AM Andrus Adamchik <aadamc...@gmail.com> wrote: > I think there's going to be quite a few. Since we got rid of ROP, we can > tighten our naming everywhere - modules, packages, classes. > > Andrus > > > > > On Nov 22, 2023, at 8:07 AM, Michael Gentry <blackn...@gmail.com> wrote: > > > > Hi Nikita! > > > > Both sound very reasonable to me, so +1 for that. > > > > Will there be any backward-compatibility breaking changes in 5.x? > > > > Thanks, > > mrg > > > > > > On Tue, Nov 21, 2023 at 3:04 AM Nikita Timofeev < > ntimof...@objectstyle.com> > > wrote: > > > >> Hi all, > >> > >> Wanted to share a couple of my thoughts about changes that could be good > >> for Cayenne. And the first milestone release of Cayenne 5.0 could be a > >> perfect target for these changes. > >> > >> 1. Get rid of the `server` part in the names everywhere, starting by > >> renaming our core dependency from `cayenne-server` to just `cayenne`. > >> As we already removed the `client` counterpart, `server` just doesn't > make > >> sense anymore. > >> > >> 2. Change of the versioning schema we use for the development cycle. A > >> short version of the proposal: drop BETA versions, keep the version of > >> snapshot build always the same, and slightly change format to articulate > >> what is the actual version. > >> > >> Format would look like `MAJOR.MINOR-QUALIFIER`. Where the qualifier is > one > >> of `SNAPSHOT`, `M` for the milestone or `RC` for the release candidate. > >> > >> Example for the 5.0: > >> - snapshot always stays as 5.0-SNAPSHOT > >> - milestones releases are 5.0-M1, 5.0-M2 etc. > >> - release candidates are 5.0-RC1, 5.0-RC2, etc. > >> - and final release is just 5.0 > >> > >> And here's a reason for that change. It solves two minor problems with > the > >> current schema. The first one is that all systems think that `B` goes > >> before `M`, so our beta versions always look older than milestones. We > are > >> not that strict about what is beta nor are we enforcing any rules, so > there > >> should be no problems with that. > >> The second one is that projects using SNAPSHOT versions should update > >> dependency every time we make a dev release. Again not a big change and > >> should not affect anything really, as there shouldn't be many projects > >> brave enough to just use SNAPSHOT. > >> > >> Note this change does not affect overall versioning, e.g. patch versions > >> like 5.0.1 or global updates like 5.1. > >> > >> > >> -- > >> Best regards, > >> Nikita Timofeev > >> > >
